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

[George P]

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 why 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.