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

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

George P <georgepanagopo@gmail.com> writes:

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

I cannot reproduce this crash, but I suspect the culprit is to be found
in the retention of the remote frame beyond the destruction of the X
server connection, which is not detected when Emacs returns to the event
loop, and remains unnoticed until set-fontset-font prompts a request to
be issued that flushes the now-destroyed connection.  Whatever code
issues this request is not robust against abrupt destruction of frames
by the IO error handler and consequently crashes attempting to
dereference the dead frame.

Please attach GDB to the running Emacs daemon and post a backtrace from
such a crash--with any luck, the code responsible will be rather
pathological and easily addressable.