GNU bug report logs -
#1310
23.0.60; Emacs daemon behaves strangely if client loses X connection
Previous Next
Full log
Message #8 received at 1310 <at> emacsbugs.donarmstrong.com (full text, mbox):
Espen Wiborg <espenhw <at> grumblesmurf.org> writes:
> 1. Start emacs with "emacs -Q -daemon"
>
> 2. Create an X frame (emacsclient -c)
>
> 3. Kill your X server (or make your window manager crash, which is how I
> initially tickled this)
>
> 4. Restart X and try to create an X frame again. This time the frame is
> blank and doesn't respond to anything; the only way to get rid of the
> frame is by killing the daemon process.
>
> Attaching gdb to the daemon process when the frame creation hangs gives
> the stacktrace below.
>
> It appears to be hanging on the yes-or-no-p at the top of server-start,
> called because cmd_error_internal calls Fkill_emacs at keyboard.c:1274.
Thanks for the detailed report!
Can you please try this patch?
I am not entirely convinced it's completely right, I can't kill my X
server at the moment, and I could not reproduce the problem with
Xnest.
--- keyboard.c.~1.978.~ 2008-11-02 21:49:25.000000000 -0800
+++ keyboard.c 2008-11-06 21:04:55.000000000 -0800
@@ -1265,7 +1265,7 @@ cmd_error_internal (data, context)
/* If the window system or terminal frame hasn't been initialized
yet, or we're not interactive, write the message to stderr and exit. */
else if (!sf->glyphs_initialized_p
- || FRAME_INITIAL_P (sf)
+ || (FRAME_INITIAL_P (sf) && !IS_DAEMON)
|| noninteractive)
{
print_error_message (data, Qexternal_debugging_output,
This bug report was last modified 15 years and 158 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.