bug#66151: 29.1.50; daemon crashing after X forwarding disconnects

[George P <georgepanagopo@gmail.com>]

Hi,

I am able to reproduce this bug without launching a new emacsclient.
Steps to reproduce:

- Start emacs daemon.
- Connect using emacsclient -c.
- Connect remotely to the daemon and run another emacsclient -c using
X forwarding.
- Crash the X forwarding connection created in the previous step.
- Go back to the emacsclient running locally on the daemon and run
(set-fontset-font t '(#xe000 . #xf8ff) "Symbols Nerd Font Mono")

The reason that Ben was seeing a crash with a new emacsclient is
because he is using Doom (an Emacs framework) that attached a function
to server-after-make-hook that called set-fontset-font in the above
way. As Eli said, there is really no good reason to run such a hook
after the first frame, and this behavior has been fixed in Doom. (To
Ben: try upgrading Doom and see if it fixes your issue, if not let me
know!)

Surprisingly, the segfault still happens even if I explicitly call
delete-frame on the dead frame before calling set-fontset-font. Also,
I am unable to reproduce this bug without Doom (i.e. launching the
daemon with -Q).

I am confused as to why emacs doesn't automatically clean up frames
that have been disconnected like this. If emacs survives a crash of
the X server, it should be able to identify that the display is dead
(e.g. by checking the validity of output_data.x) and remove it from
the (frame-list), preventing any subsequent commands from acting on
these frames. It has to do something more than what delete-frame does,
as that does not fix the issue (even though it removes the frame from
the (frame-list)).

Note: using GTK is very different, as emacs crashes *without* having
to run set-fontset-font (i.e. emacs crashes when the X forwarding
connection crashes). With lucid, emacs continues to run fine with the
exception of this bug for me.