bug#1310: 23.0.60; Emacs daemon behaves strangely if client loses X connection

[Dan Nicolaescu]

Espen Wiborg <espenhw@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,