[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23939: Segfault in daemon mode Emacs when detaching an X session

From: Noam Postavsky
Subject: bug#23939: Segfault in daemon mode Emacs when detaching an X session
Date: Sun, 05 May 2019 00:15:40 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

#14958 = emacs --daemon crashing when X-frames are removed ungracefully
#11676 = Daemon crashes when ssh dies
#22174 = emacs --daemon crashes when ssh is disconnected. I am using lucid x 
merge 14958 11676 22174
#11639 = 24.0.95; Emacs daemon hangs when emacsclient was killed
# probably the GTK thing
merge 11639 8501

Doug Gilmore <address@hidden> writes:

> I have been running my own build of Emacs 24.2 for quite a while in
> daemon mode for quite a while without any problems except that the
> daemon would on rare occasions crash when I detached a windows frame
> via the delete-frame Emacs command.  The other day this happened
> several times in succession when connecting to a daemon running on
> another host and I was able to catch the failure under an attached gdb
> session.  I attached a backtrace and a prototype fix.
> I have been building my own Emacs on Ubuntu-12/14 configured with the
> --with-x-toolkit=lucid option, so this is not a Gtk issue.
> Has anyone else been seeing this problem?

There are some other reports about Emacs daemon dying when closing X
sessions, but the backtraces look different, so I guess it's not the
same problem.

> #0  x_uncatch_errors () at /scratch/dgilmore/emacs-24.2/src/xterm.c:7672
> #1  0x00000000004cb588 in x_catch_errors_unwind (dummy=<optimized out>) at 
> /scratch/dgilmore/emacs-24.2/src/xselect.c:546
> #2  0x000000000055b4ce in unbind_to (count=<optimized out>, value=11872738) 
> at /scratch/dgilmore/emacs-24.2/src/eval.c:3433
> #3  0x000000000055b6e5 in unwind_to_catch (catch=0x7ffc44910f60, 
> value=<optimized out>) at /scratch/dgilmore/emacs-24.2/src/eval.c:1314
> #4  0x000000000055d5a9 in Fsignal (error_symbol=11924850, data=38401462) at 
> /scratch/dgilmore/emacs-24.2/src/eval.c:1764

> (gdb) p x_error_message
> $1 = (struct x_error_message_stack *) 0x0

> Subject: [PATCH] Make sure x_error_message is not NULL.
> Before dereferencing the pointer.

> @@ -7665,6 +7665,14 @@ x_uncatch_errors (void)
>  {
>    struct x_error_message_stack *tmp;
> +  /* In rare situations when running Emacs run in daemon mode,
> +     shutting down an emacsclient via delete-frame can cause
> +     x_uncatch_errors to be called when x_error_message is set to
> +     NULL.  */
> +  
> +  if (x_error_message == NULL)
> +    return;
> +

If this really is possible, I guess a NULL check wouldn't be a bad

reply via email to

[Prev in Thread] Current Thread [Next in Thread]