Re: 23.0.60; Emacs should survive a lost X connection

[Harald Hanche-Olsen]

For some reason, rms is sending out his messages on this thread with
Reply-to: address@hidden  So I had sent the reply below to him only.  By
the lack of any response I don't think he has received it; so here it
is again, with more recpipients this time.

Exececutive summary: The problem is not gone away, unless I run emacs
under gdb (!),

+ Richard Stallman <address@hidden>:

> The crash is caused by the code in Fdelete_frame
> to call the hook `delete-frame-functions'.
> I don't think that should be done while handling a disconnect
> in a signal handler.  So I changed it so that FORCE inhibits that.
> 
> Are there any more crashes due to that error check?

Fascinating.  Now, when I first repeated my experiment (that is:
emacs -nw, M-x make-frame-display RET :1 RET, then kill display :1)
I got an infinite stream of this message:

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

No idea what came before this gazillion of identical messages.
Unfortunately I am unable to reproduce it.

But I had perhaps obfuscated the test by failing to use the -q
flag. So I tried again, this time running emacs -nw -q.  Now it just
aborted (after I had done M-x make-frame-on-display RET :1 RET and
killed display :1):

Program terminated with signal 6, Aborted.
#0  0x88cb9ecb in kill () from /lib/libc.so.6
#1  0x0811ea96 in fatal_error_signal (sig=-1077959328) at emacs.c:399
#2  0x88a6af5d in sigaction () from /lib/libpthread.so.2
#3  0xbfbfff94 in ?? ()
#4  0x00000006 in ?? ()
#5  0xbfbfa930 in ?? ()
#6  0xbfbfa670 in ?? ()
#7  0x00000000 in ?? ()
#8  0x88a6aa24 in sigaction () from /lib/libpthread.so.2
#9  0x08180e2f in internal_condition_case (bfun=0x812ceb4 <command_loop_1>, 
    handlers=137829497, hfun=0x8126584 <cmd_error>) at eval.c:1469
#10 0x08120736 in command_loop_2 () at keyboard.c:1370
#11 0x08180b3d in internal_catch (tag=0, func=0x8120718 <command_loop_2>, 
    arg=137779201) at eval.c:1230
#12 0x08120548 in command_loop () at keyboard.c:1349
#13 0x081205e4 in recursive_edit_1 () at keyboard.c:958
#14 0x08120703 in Frecursive_edit () at keyboard.c:1020
#15 0x0811f9ba in main (argc=3, argv=0xbfbfac3c) at emacs.c:1794

The above is from gdb run on the core file.

So I tried yet again, this time starting emacs -nw -q and attaching
gdb to the live process before running the experiment yet again.  This
time, gdb caught a SIGPIPE that I just continued from, after which
these messages appeared:

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

(emacs:3242): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN 
(screen)' failed

(emacs:3242): GLib-GObject-CRITICAL **: g_object_get_data: assertion 
`G_IS_OBJECT (object)' failed

(emacs:3242): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN 
(screen)' failed

(emacs:3242): GLib-GObject-CRITICAL **: g_object_get_data: assertion 
`G_IS_OBJECT (object)' failed

(emacs:3242): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN 
(screen)' failed

(emacs:3242): GLib-GObject-CRITICAL **: g_object_get_data: assertion 
`G_IS_OBJECT (object)' failed

(emacs:3242): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN 
(screen)' failed

(emacs:3242): GLib-GObject-CRITICAL **: g_object_get_data: assertion 
`G_IS_OBJECT (object)' failed

Connection lost to X server `:1.0'

But then emacs acted normally again. So behaviour seems to differ
depending on whether or not I run under gdb.

- Harald