bug#54715: 28.0.92; crash when X server died

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

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

Yes, thanks.  I think the problem is that selected_frame is dead.  But
if my reading of the code is correct, x_connection_closed calls
delete_frame on all the frames on the disconnected terminal before
Fkill_emacs is called (BTW, is that really right if Emacs is running as
a daemon?), and delete_frame tries to find another frame to select,
which in this case must be the initial frame, since there are no other
terminals left.  So I think the problem lies somewhere in delete_frame.

Alternatively, selected_frame might have become dead before delete_frame
was called on the frames in the second terminal, but I don't see how
that could have happened.

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

And the selected frame was something other than the initial frame when
redisplay was called, which is probably what's at fault here.

> Or maybe we should refrain from calling redisplay_preserve_echo_area
> in delete-process when Emacs is shutting down due to a fatal error?

I think this isn't supposed to happen at all, especially since Ken is
running a daemon, so we shouldn't bubble wrap delete-process because of
this.

I will try to reproduce this again, hopefully I can get Emacs to crash
on my side as well.

Thanks.