[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54715: 28.0.92; crash when X server died
From: |
Eli Zaretskii |
Subject: |
bug#54715: 28.0.92; crash when X server died |
Date: |
Tue, 05 Apr 2022 15:16:10 +0300 |
> 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?