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

[Visuwesh <visuweshm@gmail.com>]

[புதன் ஜூலை 13, 2022] Eli Zaretskii wrote:

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

I don't think so.  Lucid toolkit has been the suggested method to
survive X crashes, and so far, it has worked.  If it involved more than
sheer luck, then I don't think people would suggest it.

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

I know about desktop.el and I do use it, but it is not the same.

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

Ignore it?  Or write it to stdout?  One can see the message in
*Messages* anyway.  I killed X the same way I did here last month and
Emacs coped just fine; the same way being M-! pkill X RET.

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

Please reconsider.  I will finally quote etc/PROBLEMS here,

    ** When Emacs is compiled with Gtk+, closing a display kills Emacs.

    There is a long-standing bug in GTK that prevents it from recovering
    from disconnects: https://gitlab.gnome.org/GNOME/gtk/issues/221

    Thus, for instance, when Emacs is run as a server on a text terminal,
    and an X frame is created, and the X server for that frame crashes or
    exits unexpectedly, Emacs must exit to prevent a GTK error that would
    result in an endless loop.

    If you need Emacs to be able to recover from closing displays, compile
    it with the Lucid toolkit instead of GTK.