bug#56528: 29.0.50; Emacs lucid segfaults when X dies

[Eli Zaretskii <eliz@gnu.org>]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: luangruo@yahoo.com,  56528@debbugs.gnu.org
> Date: Wed, 13 Jul 2022 19:48:26 +0530
> 
> >> > Btw, what do we expect Emacs to do in this scenario?  If the X server
> >> > is killed, Emacs cannot display anything, so why an abort is not TRT?
> >> > What practically interesting use case does this emulate?
> >> 
> >> Emacs is running as a daemon, I expect it to survive the death of X.
> >
> > "Survive" how? by closing all the frames?
> 
> Unfortunately, I do not start the daemon by M-x server-start RET so I do
> not know what the behaviour was here but read below. 

Starting a daemon automatically starts the server.

> > IOW, you are saying that when this happens, Emacs should test whether
> > it has a running server, and if it does, unconditionally close all the
> > frames?  Is that really useful?
> 
> In the past, when I start Emacs daemon by `emacs --daemon' in my
> ~/.xsession file and eventually kill X, Emacs will not die.  I can still
> access the Emacs session in the tty or a fresh Xorg session using
> emacsclient.  But I seem to recall M-x server-start RET working
> identical to --daemon here.

That's probably just sheer luck.  When you kill the X server, any code
in Emacs that tries to display something will crash and burn, because
there's generally no way for us to display anything in that case.

> >> Emacs dying on me because I killed X is an annoyance since sometimes I
> >> need to restart X.
> >
> > Why not close Emacs before that -- this way you get to keep all your
> > edits, instead of relying on error handling to succeed in doing that.
> 
> That's not a solution, sorry.  Just saving the buffers is not going to
> cut it, I would like to have my shell session, other processes stay
> alive.

Our solution to this is desktop.el.  You can customize it to save and
restore more than it does by default.  But expecting Emacs to survive
the killing of X is unreasonable.

> Hmm, trying it with --fg-daemon, sometimes Emacs survives, sometimes it
> dies.  Backtrace follows,
> 
> (gdb) run -Q --fg-daemon
> Starting program: /home/viz/lib/ports/emacs/src/emacs -Q --fg-daemon
> [Switching to thread 1 (process 7339)](running)
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7ffff15fe640 (LWP 7340)]
> [New Thread 0x7ffff0c6d640 (LWP 7356)]
> [New Thread 0x7fffebfff640 (LWP 7357)]
> [Detaching after vfork from child process 7393]
> 
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> message3_nolog (m=...) at xdisp.c:11770
> 11770	      if (FRAME_TERMINAL (f)->frame_up_to_date_hook)
> (gdb) bt
> #0  message3_nolog (m=XIL(0x555556066254)) at xdisp.c:11770
> #1  0x00005555555f3449 in message3 (m=XIL(0x555556066254)) at xdisp.c:11698
> #2  0x0000555555848e28 in Fmessage (nargs=2, args=0x7ffff15ff250) at editfns.c:2881

Here's an excellent example of what I was trying to say: this says
that Emacs tried to show some message, and crashed because that
requires a valid frame with a terminal connection.  What do you expect
Emacs to do here?

I think we should close this bug as wontfix.  It's unreasonable to
expect a GUI program to stay in the air when its GUI infrastructure is
forcibly killed.