[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56528: 29.0.50; Emacs lucid segfaults when X dies
From: |
Visuwesh |
Subject: |
bug#56528: 29.0.50; Emacs lucid segfaults when X dies |
Date: |
Wed, 13 Jul 2022 22:50:30 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
[புதன் ஜூலை 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.
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, (continued)
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Visuwesh, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Visuwesh, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Visuwesh, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Visuwesh, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies,
Visuwesh <=
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Po Lu, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/14
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Po Lu, 2022/07/14
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/14
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Po Lu, 2022/07/13
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/14
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Po Lu, 2022/07/14
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Eli Zaretskii, 2022/07/14
- bug#56528: 29.0.50; Emacs lucid segfaults when X dies, Po Lu, 2022/07/14