bug#54715: 28.0.92; crash when X server died

[Eli Zaretskii]

> Cc: 54715@debbugs.gnu.org
> Date: Tue, 05 Apr 2022 09:05:19 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> > #28 0x0000000000422866 in x_connection_closed (dpy=dpy@entry=0x511fc50, 
> > error_message=error_message@entry=0x7ffde15e78e8 "Connection lost to X 
> > server ':0.0'", ioerror=ioerror@entry=true) at ../../src/xterm.c:10240
> 
> x_connection_closed binds inhibit-redisplay to t, so redisplay cannot do
> anything interesting inside.

True.

> > #12 0x00000000004202a3 in redisplay_internal () at ../../src/xdisp.c:15633
> 
> But this frame shows that it did try to do something, and aborted.

It looks like it aborted trying to do nothing ;-)

> Unfortunately, I don't see anything interesting at line 15633 in Emacs
> 28.

I do see something interesting (did you look in 28.0.92 sources?):

  /* No redisplay if running in batch mode or frame is not yet fully
     initialized, or redisplay is explicitly turned off by setting
     Vinhibit_redisplay.  */
  if ((FRAME_INITIAL_P (SELECTED_FRAME ())  <<<<<<<<<<<<<<<<<<<<<<<<<
       && redisplay_skip_initial_frame)
      || !NILP (Vinhibit_redisplay))
    return;

Crystal ball says something is wrong with SELECTED_FRAME, and that
causes the abort.

My guess would be that Ken's kill-emacs-hooks were called when the X
server died, and one of those hooks is unsafe, in that it causes
redisplay.  Or maybe we should refrain from calling
redisplay_preserve_echo_area in delete-process when Emacs is shutting
down due to a fatal error?