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

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

[Espen Wiborg]

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.

#0  0xb80c6430 in __kernel_vsyscall ()
#1  0xb752dbcd in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x081cdbea in wait_reading_process_output (time_limit=0, 
    microsecs=0, read_kbd=-1, do_display=1, 
    wait_for_cell=137944345, wait_proc=0x0, just_wait_proc=0)
    at process.c:4450
#3  0x08130498 in read_char (commandflag=1, nmaps=2, 
    maps=0xbfdc7780, prev_event=137944345, 
    used_mouse_menu=0xbfdc7830, end_time=0x0) at keyboard.c:4038
#4  0x081323b2 in read_key_sequence (keybuf=0xbfdc78e4, 
    bufsize=30, prompt=137944345, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1)
    at keyboard.c:9344
#5  0x08134013 in command_loop_1 () at keyboard.c:1621
#6  0x08190410 in internal_condition_case (
    bfun=0x8133e30 <command_loop_1>, handlers=137987553, 
    hfun=0x812d940 <cmd_error>) at eval.c:1511
#7  0x0812cea5 in command_loop_2 () at keyboard.c:1338
#8  0x081904ea in internal_catch (tag=138082801, 
    func=0x812ce80 <command_loop_2>, arg=137944345) at eval.c:1247
#9  0x0812d747 in command_loop () at keyboard.c:1303
#10 0x0812db3b in recursive_edit_1 () at keyboard.c:942
#11 0x08150545 in read_minibuf (map=137937349, initial=137944345, 
    prompt=<value optimized out>, backup_n=<value optimized out>, 
    expflag=0, histvar=138087945, histpos=0, defalt=137944345, 
#12 0x0819dba6 in Fyes_or_no_p (prompt=141802059) at fns.c:2792
#13 0x08191134 in Ffuncall (nargs=2, args=0xbfdc7cb0)
    at eval.c:3044
#14 0x081c6398 in Fbyte_code (bytestr=143351939, 
    vector=147504412, maxdepth=<value optimized out>)
    at bytecode.c:678
#15 0x08192f53 in funcall_lambda (fun=145209676, nargs=1, 
    arg_vector=0xbfdc7e34) at eval.c:3231
#16 0x08190e13 in Ffuncall (nargs=2, args=0xbfdc7e30)
    at eval.c:3101
#17 0x081c6398 in Fbyte_code (bytestr=143296619, 
    vector=145272100, maxdepth=<value optimized out>)
    at bytecode.c:678
#18 0x08192f53 in funcall_lambda (fun=144357524, nargs=1, 
    arg_vector=0xbfdc7f64) at eval.c:3231
#19 0x08190e13 in Ffuncall (nargs=2, args=0xbfdc7f60)
    at eval.c:3101
#20 0x081c6398 in Fbyte_code (bytestr=143355483, 
    vector=145176892, maxdepth=<value optimized out>)
    at bytecode.c:678
#21 0x08192f53 in funcall_lambda (fun=145193476, nargs=0, 
    arg_vector=0xbfdc80cc) at eval.c:3231
#22 0x08190e13 in Ffuncall (nargs=1, args=0xbfdc80c8)
    at eval.c:3101
#23 0x081921b1 in run_hook_with_args (nargs=1, args=0xbfdc80c8, 
    cond=to_completion) at eval.c:2703
#24 0x08192372 in Frun_hooks (nargs=1, args=0xbfdc8164)
    at eval.c:2566
#25 0x08190fbe in Ffuncall (nargs=2, args=0xbfdc8160)
    at eval.c:3025
#26 0x08192039 in call1 (fn=138083185, arg1=138132537)
    at eval.c:2829
#27 0x081227b5 in Fkill_emacs (arg=-8) at emacs.c:2076
#28 0x0812d925 in cmd_error_internal (data=143401285, 
    context=0xbfdc81c6 "") at keyboard.c:1274
#29 0x0812da27 in cmd_error (data=143401285) at keyboard.c:1222
#30 0x0819043c in internal_condition_case (
    bfun=0x8133e30 <command_loop_1>, handlers=137987553, 
    hfun=0x812d940 <cmd_error>) at eval.c:1501
#31 0x0812cea5 in command_loop_2 () at keyboard.c:1338
#32 0x081904ea in internal_catch (tag=137983529, 
    func=0x812ce80 <command_loop_2>, arg=137944345) at eval.c:1247
#33 0x0812d79f in command_loop () at keyboard.c:1317
#34 0x0812db3b in recursive_edit_1 () at keyboard.c:942
#35 0x0812dc84 in Frecursive_edit () at keyboard.c:1004
#36 0x081239df in main (argc=3, argv=0xbfdc8804) at emacs.c:1777

Lisp Backtrace:
"yes-or-no-p" (0xbfdc7cb4)
"server-start" (0xbfdc7e34)
"server-mode" (0xbfdc7f64)
0x8a77a04 PVEC_COMPILED
"run-hooks" (0xbfdc8164)

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,

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

[Espen Wiborg]

On Mon, November 10, 2008 09:29, Dan Nicolaescu wrote:
> "Espen Wiborg" <espenhw@grumblesmurf.org> writes:
>   > With the patch the behavior is less deterministic:
>   >
>   > Emacs usually survives the first X crash, and will at this point happily serve
>   > clients and create frames.
>   >
>   > The second crash usually calls abort() with the following backtrace:
>
> Unfortunately, I am still not able to play with killing X, so I can only
> offer guesses, but no real debugging...

I test by starting the daemon under a different name (./emacs -Q --daemon=testing) and
then run a secondary X server serving just the client with

startx `which emacsclient` -c -s /tmp/emacs`id -u`/testing -- :1

I can then zap the secondary X, e.g. with C-M-Backspace, without affecting my real session.

This trick is also useful to test strange resolutions, color depths etc.

> Does the problem happen if you configure emacs without Gtk (i.e.
> --with-x-toolkit=lucid)?

No, it doesn't.  Or at least it happens much less frequently; in 35-40 tries I could
only provoke something once, but that seems to have been a clean shutdown (which is
infinitely preferable to the hang I get with Gtk enabled).

> Also, can you try if the problem happens if you do:
> in a text console: emacs -Q -f server-start
> now start X, and run emacsclient -c to connect to the server
> and kill X
> (this is to verify if the problem is related to --daemon, I am guessing
> it should not be, and similar problems were fixed long time ago...)

Interesting.  With the Gtk-enabled Emacs, I get the same behavior as with --daemon, but
when I try to open a new frame after killing X, my console is spammed with

(emacs:6078): GLib-WARNING **: g_main_context_prepare() called recursively from within a
source's check() or prepare() member.

ad infinitum.

So it definitely looks as if Gtk is the culprit (or at least part of the problem).

I'm running this on Ubuntu 8.10, Intrepid Ibex; I appeare to have Gtk 2.14.4-0ubuntu1
installed.

-- 
Espen Wiborg <espenhw@grumblesmurf.org> - Veritas vos liberabit
A twisted mind is a joy forever.