23.0.60; Emacs should survive a lost X connection

23.0.60; Emacs should survive a lost X connection

[Harald Hanche-Olsen]

What I did: a deliberate test, not an accident -
(and my apologies in the likely case that this is well known):

I started emacs -nw, then ran M-x make-frame-on-display RET :0 RET.
After the new frame popped up on display :0 (I did all this from an
xterm not on that display), I logged out of display :0.
Emacs aborted as a result.

Here is the top of the backtrace.

; gdb /local/bin/emacs core
Core was generated by `emacs'.
Program terminated with signal 6, Aborted.
(gdb) back
#0  0x88c5eecb in kill () from /lib/libc.so.6
#1  0x080f860e in fatal_error_signal (sig=-1077966240) at emacs.c:398
#2  0x88a44f5d in sigaction () from /lib/libpthread.so.2
#3  0xbfbfff94 in ?? ()
#4  0x00000006 in ?? ()
#5  0xbfbf8e30 in ?? ()
#6  0xbfbf8b70 in ?? ()
#7  0x00000000 in ?? ()
#8  0x88a44a24 in sigaction () from /lib/libpthread.so.2
#9  0x0815a954 in internal_condition_case_2 (
    bfun=0x815d5e0 <Frun_hook_with_args>, nargs=2, args=0xbfbf8f68, 
    handlers=137623601, hfun=0x805cfe4 <delete_frame_handler>) at eval.c:1568
#10 0x0805fd91 in Fdelete_frame (frame=137838641, force=137623601)
    at frame.c:1412
#11 0x080d5266 in x_connection_closed (dpy=0x860f335, 
    error_message=0xbfbf9080 "Connection lost to X server `:0.0'")
    at xterm.c:8054

I am pretty sure this at the top of internal_condition_case_2
(eval.c:1568) is responsible:

eval.c:1568 is where it dies deliberately:
  /* Since Fsignal will close off all calls to x_catch_errors,
     we will get the wrong results if some are not closed now.  */
#if HAVE_X_WINDOWS
  if (x_catching_errors ())
    abort ();
#endif

I am guessing that the code was not written for a lost X connection to
be survivable, but perhaps I am wrong.  But if I guessed right,
consider this a feature request rather than a bug report:  For
multitty to be really useful, I think surviving a lost X connection
can be important.  Dropped connections can easily happen when
accessing the office computer from a laptop, for example.


In GNU Emacs 23.0.60.2 (i386-unknown-freebsd6.2, GTK+ Version 2.12.7)
 of 2008-02-03 on fiinbeck.math.ntnu.no
Windowing system distributor `The X.Org Foundation', version 11.0.10400000
configured using `configure  '--prefix' '/local''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

(Various other stuff elided, as it did not come from the dead emacs.)

- Harald

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

  > What I did: a deliberate test, not an accident -
  > (and my apologies in the likely case that this is well known):
  > 
  > I started emacs -nw, then ran M-x make-frame-on-display RET :0 RET.
  > After the new frame popped up on display :0 (I did all this from an
  > xterm not on that display), I logged out of display :0.
  > Emacs aborted as a result.


This used to work, not sure when it broke...

Re: 23.0.60; Emacs should survive a lost X connection

[Harald Hanche-Olsen]

Oh, so there is an emacs-pretest-bug mailing list after all ... I
guess it's just its web interface that seems to have gone silent
since August (http://lists.gnu.org/archive/html/emacs-pretest-bug/).

So I had posted my message to bug-gnu-emacs as well.  I am sorry to be
splitting up the discussion like that.  (Maybe someone ought to go fix
the web interface?  It is confusing.)

- Harald

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
  > 
  >   > What I did: a deliberate test, not an accident -
  >   > (and my apologies in the likely case that this is well known):
  >   > 
  >   > I started emacs -nw, then ran M-x make-frame-on-display RET :0 RET.
  >   > After the new frame popped up on display :0 (I did all this from an
  >   > xterm not on that display), I logged out of display :0.
  >   > Emacs aborted as a result.
  > 
  > 
  > This used to work, not sure when it broke...

It broke because of this change:

2007-09-29  Richard Stallman  <rms@gnu.org>

            * eval.c (internal_condition_case_2, internal_condition_case_1)
            (internal_condition_case): Reenable abort if x_catching_errors ()
            to see if that really happens and why.


Richard, now you have part of the answer: if the X11 connection is lost
emacs crashes after your patch. It works fine after undoing the patch.
(Undoing this patch also solves another issue discussed recently: emacs
crashes after using xkill on an emacsclient frame).

Re: 23.0.60; Emacs should survive a lost X connection

[Richard Stallman]

		* eval.c (internal_condition_case_2, internal_condition_case_1)
		(internal_condition_case): Reenable abort if x_catching_errors ()
		to see if that really happens and why.


    Richard, now you have part of the answer: if the X11 connection is lost
    emacs crashes after your patch. It works fine after undoing the patch.

Interesting.  Can you send me a backtrace for that crash?

    (Undoing this patch also solves another issue discussed recently: emacs
    crashes after using xkill on an emacsclient frame).

I'd like to see a backtrace for that case too.

The idea is, if there is a good reason for those calls to be where
they are, then the right thing is to undo my patch and add comments
explaining in detail why it is legitimate for those functions to
be called with x_catching_errors in effect.  But if it is clean
to get rid of those calls, and handle those cases differently,
that is better.

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > 		* eval.c (internal_condition_case_2, internal_condition_case_1)
  > 		(internal_condition_case): Reenable abort if x_catching_errors ()
  > 		to see if that really happens and why.
  > 
  > 
  >     Richard, now you have part of the answer: if the X11 connection is lost
  >     emacs crashes after your patch. It works fine after undoing the patch.
  > 
  > Interesting.  Can you send me a backtrace for that crash?

Sure: 

#0  abort () at /tmp/emacs/src/emacs.c:432
#1  0x081627ad in internal_condition_case_2 (bfun=0x81655b0 <Frun_hook_with_args>, nargs=2, args=0xbfbcc6c4, handlers=137640185, 
    hfun=0x805cb30 <delete_frame_handler>) at /tmp/emacs/src/eval.c:1573
#2  0x0805d451 in Fdelete_frame (frame=146544260, force=137640185) at /tmp/emacs/src/frame.c:1412
#3  0x080d4cf5 in x_connection_closed (dpy=0x87f6b88, error_message=<value optimized out>)
    at /tmp/emacs/src/xterm.c:8054
#4  0x080d4dbb in x_io_error_quitter (display=0x87f6b88) at /tmp/emacs/src/xterm.c:8202
#5  0x00206fc2 in _XIOError () from /usr/lib/libX11.so.6
#6  0x0020dbb9 in ?? () from /usr/lib/libX11.so.6
#7  0x0020df9f in _XEventsQueued () from /usr/lib/libX11.so.6
#8  0x001f76d2 in XPending () from /usr/lib/libX11.so.6
#9  0x080d876e in XTread_socket (terminal=0x8853f48, expected=1, hold_quit=0xbfbccfa4)
    at /tmp/emacs/src/xterm.c:7366
#10 0x081019df in read_avail_input (expected=1) at /tmp/emacs/src/keyboard.c:7110
#11 0x08101b0a in handle_async_input () at /tmp/emacs/src/keyboard.c:7340
#12 0x08101cd1 in input_available_signal (signo=29) at /tmp/emacs/src/keyboard.c:7382
#13 <signal handler called>
#14 0x00110402 in __kernel_vsyscall ()
#15 0x007eb5bd in ___newselect_nocancel () from /lib/libc.so.6
#16 0x08190f05 in select_wrapper (n=1, rfd=0x0, wfd=0xbfbcd528, xfd=0x0, tmo=0xbfbcd658)
    at /tmp/emacs/src/process.c:4240
#17 0x08194110 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137640137, 
    wait_proc=0x0, just_wait_proc=0) at /tmp/emacs/src/process.c:4610
#18 0x08052220 in sit_for (timeout=240, reading=1, do_display=1) at /tmp/emacs/src/dispnew.c:6608
#19 0x08106dbd in read_char (commandflag=1, nmaps=2, maps=0xbfbcd930, prev_event=137640137, used_mouse_menu=0xbfbcd9d8, 
    end_time=0x0) at /tmp/emacs/src/keyboard.c:2969
#20 0x08108b0a in read_key_sequence (keybuf=0xbfbcda74, bufsize=30, prompt=137640137, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:9460
#21 0x0810a9a3 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1655
#22 0x08162ab2 in internal_condition_case (bfun=0x810a800 <command_loop_1>, handlers=137684369, hfun=0x8104f70 <cmd_error>)
    at /tmp/emacs/src/eval.c:1496
#23 0x081043e3 in command_loop_2 () at /tmp/emacs/src/keyboard.c:1370
#24 0x08162b6a in internal_catch (tag=137679217, func=0x81043c0 <command_loop_2>, arg=137640137)
    at /tmp/emacs/src/eval.c:1230
#25 0x08104dd7 in command_loop () at /tmp/emacs/src/keyboard.c:1349
#26 0x0810513a in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:958
#27 0x08105271 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1020
#28 0x080faa97 in main (argc=5, argv=0xbfbce174) at /tmp/emacs/src/emacs.c:1793

(This is from doing:
emacs -Q -nw -f server-start 
in a terminal,
then on another display:
emacsclient -c -d $DISPLAY
then kill X11)

  >     (Undoing this patch also solves another issue discussed recently: emacs
  >     crashes after using xkill on an emacsclient frame).
  > 
  > I'd like to see a backtrace for that case too.

Here it is:

#0  abort () at /tmp/emacs/src/emacs.c:432
#1  0x081627ad in internal_condition_case_2 (bfun=0x81655b0 <Frun_hook_with_args>, nargs=2, args=0xbfaf8de4, handlers=137640185, 
    hfun=0x805cb30 <delete_frame_handler>) at /tmp/emacs/src/eval.c:1573
#2  0x0805d451 in Fdelete_frame (frame=146544260, force=137640185) at /tmp/emacs/src/frame.c:1412
#3  0x080d4cf5 in x_connection_closed (dpy=0x87f6b88, error_message=<value optimized out>)
    at /tmp/emacs/src/xterm.c:8054
#4  0x080d4dbb in x_io_error_quitter (display=0x87f6b88) at /tmp/emacs/src/xterm.c:8202
#5  0x00206fc2 in _XIOError () from /usr/lib/libX11.so.6
#6  0x0020dbb9 in ?? () from /usr/lib/libX11.so.6
#7  0x0020df9f in _XEventsQueued () from /usr/lib/libX11.so.6
#8  0x001f76d2 in XPending () from /usr/lib/libX11.so.6
#9  0x080d876e in XTread_socket (terminal=0x8853f48, expected=1, hold_quit=0xbfaf96c4)
    at /tmp/emacs/src/xterm.c:7366
#10 0x081019df in read_avail_input (expected=1) at /tmp/emacs/src/keyboard.c:7110
#11 0x08101b0a in handle_async_input () at /tmp/emacs/src/keyboard.c:7340
#12 0x08101cd1 in input_available_signal (signo=29) at /tmp/emacs/src/keyboard.c:7382
#13 <signal handler called>
#14 0x00110402 in __kernel_vsyscall ()
#15 0x007eb5bd in ___newselect_nocancel () from /lib/libc.so.6
#16 0x08190f05 in select_wrapper (n=1, rfd=0x0, wfd=0xbfaf9c48, xfd=0x0, tmo=0xbfaf9d78)
    at /tmp/emacs/src/process.c:4240
#17 0x08194110 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137640137, 
    wait_proc=0x0, just_wait_proc=0) at /tmp/emacs/src/process.c:4610
#18 0x08052220 in sit_for (timeout=240, reading=1, do_display=1) at /tmp/emacs/src/dispnew.c:6608
#19 0x08106dbd in read_char (commandflag=1, nmaps=2, maps=0xbfafa050, prev_event=137640137, used_mouse_menu=0xbfafa0f8, 
    end_time=0x0) at /tmp/emacs/src/keyboard.c:2969
#20 0x08108b0a in read_key_sequence (keybuf=0xbfafa194, bufsize=30, prompt=137640137, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:9460
#21 0x0810a9a3 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1655
#22 0x08162ab2 in internal_condition_case (bfun=0x810a800 <command_loop_1>, handlers=137684369, hfun=0x8104f70 <cmd_error>)
    at /tmp/emacs/src/eval.c:1496
#23 0x081043e3 in command_loop_2 () at /tmp/emacs/src/keyboard.c:1370
#24 0x08162b6a in internal_catch (tag=137679217, func=0x81043c0 <command_loop_2>, arg=137640137)
    at /tmp/emacs/src/eval.c:1230
#25 0x08104dd7 in command_loop () at /tmp/emacs/src/keyboard.c:1349
#26 0x0810513a in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:958
#27 0x08105271 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1020
#28 0x080faa97 in main (argc=5, argv=0xbfafa894) at /tmp/emacs/src/emacs.c:1793

The above is from:
emacs -Q -nw -f server-start
from another xterm:
emacsclient -c -d :0

from yet another xterm:

xkill

and click on the X11 frame created by emacsclient


The abort is because of this code in internal_condition_case_2:

#if HAVE_X_WINDOWS
  if (x_catching_errors ())
    abort ();
#endif

x_connection_closed does an:

  x_catch_errors (dpy);

but the condition that x_catching_errors looks for is different. (I have no idea whether this is relevant or not).

Re: 23.0.60; Emacs should survive a lost X connection

[Richard Stallman]

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?

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > 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?

No, the crashes are gone.  But the server does not seem to know that the
clients have gone, it gives a warning when trying to exit because it
thinks that clients are still connected.

Re: 23.0.60; Emacs should survive a lost X connection

[Richard Stallman]

    No, the crashes are gone.  But the server does not seem to know that the
    clients have gone, it gives a warning when trying to exit because it
    thinks that clients are still connected.

I do not understand.  When you say "server" do you mean "X server"?
Do you mean that it doesn't notice that it has been disconnected from
Emacs?

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     No, the crashes are gone.  But the server does not seem to know that the
  >     clients have gone, it gives a warning when trying to exit because it
  >     thinks that clients are still connected.
  > 
  > I do not understand.  When you say "server" do you mean "X server"?

No, I mean the emacs server, i.e. the one started by M-x server-start.

  > Do you mean that it doesn't notice that it has been disconnected
  > from Emacs?

No, the emacs server keeps track of the number of emacsclients that are
still connected, when that number is > 0 and you are doing C-x C-c it
will warn that emacsclients are still connected 
(see server-kill-emacs-query-function)

In the case described here, there are no emacsclients that are still
connected (they have died when X has died, or have been killed with
xkill), but the server thinks otherwise.

Re: 23.0.60; Emacs should survive a lost X connection

[Stefan Monnier]

>> No, the crashes are gone.  But the server does not seem to know that the
>> clients have gone, it gives a warning when trying to exit because it
>> thinks that clients are still connected.
>> 
>> I do not understand.  When you say "server" do you mean "X server"?

> No, I mean the emacs server, i.e. the one started by M-x server-start.

>> Do you mean that it doesn't notice that it has been disconnected
>> from Emacs?

> No, the emacs server keeps track of the number of emacsclients that are
> still connected, when that number is > 0 and you are doing C-x C-c it
> will warn that emacsclients are still connected 
> (see server-kill-emacs-query-function)

> In the case described here, there are no emacsclients that are still
> connected (they have died when X has died, or have been killed with
> xkill), but the server thinks otherwise.

Actually, server.el does not keep track of a count of client, it keeps
track of actual clients directly, so we should be able to check
the client's liveness and discard the dead ones.

I lost the beginning of this thread, could you give a recipe and
description for this problem?


        Stefan

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> No, the crashes are gone.  But the server does not seem to know that the
  > >> clients have gone, it gives a warning when trying to exit because it
  > >> thinks that clients are still connected.
  > >> 
  > >> I do not understand.  When you say "server" do you mean "X server"?
  > 
  > > No, I mean the emacs server, i.e. the one started by M-x server-start.
  > 
  > >> Do you mean that it doesn't notice that it has been disconnected
  > >> from Emacs?
  > 
  > > No, the emacs server keeps track of the number of emacsclients that are
  > > still connected, when that number is > 0 and you are doing C-x C-c it
  > > will warn that emacsclients are still connected 
  > > (see server-kill-emacs-query-function)
  > 
  > > In the case described here, there are no emacsclients that are still
  > > connected (they have died when X has died, or have been killed with
  > > xkill), but the server thinks otherwise.
  > 
  > Actually, server.el does not keep track of a count of client, it keeps
  > track of actual clients directly, so we should be able to check
  > the client's liveness and discard the dead ones.
  > 
  > I lost the beginning of this thread, could you give a recipe and
  > description for this problem?

Sure:

emacs -Q -nw -f server-start

emacsclient -c -d $DISPLAY&

xkill 
the emacsclient X11 frame

then C-x C-c in the emacs -nw frame will warn about clients still being
connected.

Same thing when instead of using xkill, kill X11.

Re: 23.0.60; Emacs should survive a lost X connection

[Stefan Monnier]

>> >> No, the crashes are gone.  But the server does not seem to know that the
>> >> clients have gone, it gives a warning when trying to exit because it
>> >> thinks that clients are still connected.
>> >> 
>> >> I do not understand.  When you say "server" do you mean "X server"?
>> 
>> > No, I mean the emacs server, i.e. the one started by M-x server-start.
>> 
>> >> Do you mean that it doesn't notice that it has been disconnected
>> >> from Emacs?
>> 
>> > No, the emacs server keeps track of the number of emacsclients that are
>> > still connected, when that number is > 0 and you are doing C-x C-c it
>> > will warn that emacsclients are still connected 
>> > (see server-kill-emacs-query-function)
>> 
>> > In the case described here, there are no emacsclients that are still
>> > connected (they have died when X has died, or have been killed with
>> > xkill), but the server thinks otherwise.
>> 
>> Actually, server.el does not keep track of a count of client, it keeps
>> track of actual clients directly, so we should be able to check
>> the client's liveness and discard the dead ones.
>> 
>> I lost the beginning of this thread, could you give a recipe and
>> description for this problem?

> emacs -Q -nw -f server-start

> emacsclient -c -d $DISPLAY&

> xkill 
> the emacsclient X11 frame

> then C-x C-c in the emacs -nw frame will warn about clients still being
> connected.

Indeed I can reproduce the problem, but the emacsclient is indeed not
dead, so the warning isn't wrong.  But I guess the problem here is that
since the emacsclient asked "-c" and did not specify any file to visit,
it would make a lot of sense to terminate the emacsclient when the frame
gets deleted.


        Stefan

Re: 23.0.60; Emacs should survive a lost X connection

[Richard Stallman]

      But I guess the problem here is that
    since the emacsclient asked "-c" and did not specify any file to visit,
    it would make a lot of sense to terminate the emacsclient when the frame
    gets deleted.

Why not terminate it immediately?
If it specifies no file, why wait?

Re: 23.0.60; Emacs should survive a lost X connection

[Stefan Monnier]

> emacs -Q -nw -f server-start

> emacsclient -c -d $DISPLAY&

> xkill 
> the emacsclient X11 frame

> then C-x C-c in the emacs -nw frame will warn about clients still being
> connected.

I installed a patch which refines Richard's fix and brings back the
correct "close the client connection" when you close a frame by sending
an X11 "delete" message.  This doesn't solve the above problem because
in that case, the "delete_frame" execution is run at a time where Elisp
cannot be executed.
We need to add some way for Elisp to be informed when frames are
forcefully closed because of something like an `xkill'.  Maybe we just
need to add a `after-delete-terminal-functions', which is run sometime
after deleting a terminal.  Or as suggested by some brilliant mind (at
the end of x_connection_closed):

  /* FIXME: This is an asynchronous interrupt w.r.t elisp, so signalling an
     error might not be the best thing to do.  I'd vote for creating an
     elisp event and stuffing it in the queue so people can bind to it via
     the global map.  --Stef  */

Actually, the global map is probably not a good idea, but the
special-event-map sounds about right for this.

As it turns out, most users of delete-frame-functions really want to
detect a delete-terminal rather than a delete-frame, so maybe we should
think about improving this.  This said, the xt-mouse and
xterm-extra-modifiers need to react to delete-terminal *before* the
conection is closed, rather than after, so we probably need both
a before-delete-terminal-functions (not guaranteed to be run), and some
delete-terminal event (guaranteed to be generated).


        Stefan

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > emacs -Q -nw -f server-start
  > 
  > > emacsclient -c -d $DISPLAY&
  > 
  > > xkill 
  > > the emacsclient X11 frame
  > 
  > > then C-x C-c in the emacs -nw frame will warn about clients still being
  > > connected.
  > 
  > I installed a patch which refines Richard's fix and brings back the
  > correct "close the client connection" when you close a frame by sending
  > an X11 "delete" message.  This doesn't solve the above problem because
  > in that case, the "delete_frame" execution is run at a time where Elisp
  > cannot be executed.

Now emacs aborts after emacsclient is xkilled.
Backtrace:

#0  abort () at /tmp/emacs/src/emacs.c:429
#1  0x08147ecf in internal_condition_case_2 (bfun=0x81492e0 <Frun_hook_with_args>, nargs=2, args=0xbf9f2a18, handlers=137504169, 
    hfun=0x80596d8 <delete_frame_handler>) at /tmp/emacs/src/eval.c:1568
#2  0x080598ab in Fdelete_frame (frame=147758716, force=137704913) at /tmp/emacs/src/frame.c:1424
#3  0x080cb0bd in x_connection_closed (dpy=0x87db258, error_message=0xbf9f2ce0 "Connection lost to X server `:0.0'")
    at /tmp/emacs/src/xterm.c:8078
#4  0x080cb332 in x_io_error_quitter (display=0x87db258) at /tmp/emacs/src/xterm.c:8226
#5  0x00206fc2 in _XIOError () from /usr/lib/libX11.so.6
#6  0x0020dbb9 in ?? () from /usr/lib/libX11.so.6
#7  0x0020df9f in _XEventsQueued () from /usr/lib/libX11.so.6
#8  0x001f76d2 in XPending () from /usr/lib/libX11.so.6
#9  0x080ca571 in XTread_socket (terminal=0x8b9d2e0, expected=1, hold_quit=0xbf9f2fa0)
    at /tmp/emacs/src/xterm.c:7408
#10 0x080f36d7 in read_avail_input (expected=1) at /tmp/emacs/src/keyboard.c:7114
#11 0x080f39fe in handle_async_input () at /tmp/emacs/src/keyboard.c:7340
#12 0x080f3a31 in input_available_signal (signo=29) at /tmp/emacs/src/keyboard.c:7382
#13 <signal handler called>
#14 0x00110402 in __kernel_vsyscall ()
#15 0x007eb5bd in ___newselect_nocancel () from /lib/libc.so.6
#16 0x0817440d in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137504121, 
    wait_proc=0x0, just_wait_proc=0) at /tmp/emacs/src/process.c:4586
#17 0x08057299 in sit_for (timeout=240, reading=1, do_display=1) at /tmp/emacs/src/dispnew.c:6608
#18 0x080ef072 in read_char (commandflag=1, nmaps=2, maps=0xbf9f3830, prev_event=137504121, used_mouse_menu=0xbf9f3858, 
    end_time=0x0) at /tmp/emacs/src/keyboard.c:2969
#19 0x080f6082 in read_key_sequence (keybuf=0xbf9f39a0, bufsize=30, prompt=137504121, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:9459
#20 0x080eccf8 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1655
#21 0x08147d96 in internal_condition_case (bfun=0x80eca38 <command_loop_1>, handlers=137548353, hfun=0x80ec504 <cmd_error>)
    at /tmp/emacs/src/eval.c:1494
#22 0x080ec7d6 in command_loop_2 () at /tmp/emacs/src/keyboard.c:1370
#23 0x08147907 in internal_catch (tag=137543201, func=0x80ec7b8 <command_loop_2>, arg=137504121)
    at /tmp/emacs/src/eval.c:1230
#24 0x080ec764 in command_loop () at /tmp/emacs/src/keyboard.c:1349
#25 0x080ec188 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:958
#26 0x080ec2c8 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1020
#27 0x080eb15b in main (argc=5, argv=0xbf9f3f94) at /tmp/emacs/src/emacs.c:1786

Re: 23.0.60; Emacs should survive a lost X connection

[Stefan Monnier]

>> > emacs -Q -nw -f server-start
>> 
>> > emacsclient -c -d $DISPLAY&
>> 
>> > xkill 
>> > the emacsclient X11 frame
>> 
>> > then C-x C-c in the emacs -nw frame will warn about clients still being
>> > connected.
>> 
>> I installed a patch which refines Richard's fix and brings back the
>> correct "close the client connection" when you close a frame by sending
>> an X11 "delete" message.  This doesn't solve the above problem because
>> in that case, the "delete_frame" execution is run at a time where Elisp
>> cannot be executed.

> Now emacs aborts after emacsclient is xkilled.

There was a trivial typo in my first commit, which I fixed in
a subsequent commit.  You may just have checked it out between the two.
I don't see any crashes here, so please try again,


        Stefan


> Backtrace:

> #0  abort () at /tmp/emacs/src/emacs.c:429
> #1  0x08147ecf in internal_condition_case_2 (bfun=0x81492e0 <Frun_hook_with_args>, nargs=2, args=0xbf9f2a18, handlers=137504169, 
>     hfun=0x80596d8 <delete_frame_handler>) at /tmp/emacs/src/eval.c:1568
> #2  0x080598ab in Fdelete_frame (frame=147758716, force=137704913) at /tmp/emacs/src/frame.c:1424
> #3  0x080cb0bd in x_connection_closed (dpy=0x87db258, error_message=0xbf9f2ce0 "Connection lost to X server `:0.0'")
>     at /tmp/emacs/src/xterm.c:8078
> #4  0x080cb332 in x_io_error_quitter (display=0x87db258) at /tmp/emacs/src/xterm.c:8226
> #5  0x00206fc2 in _XIOError () from /usr/lib/libX11.so.6
> #6  0x0020dbb9 in ?? () from /usr/lib/libX11.so.6
> #7  0x0020df9f in _XEventsQueued () from /usr/lib/libX11.so.6
> #8  0x001f76d2 in XPending () from /usr/lib/libX11.so.6
> #9  0x080ca571 in XTread_socket (terminal=0x8b9d2e0, expected=1, hold_quit=0xbf9f2fa0)
>     at /tmp/emacs/src/xterm.c:7408
> #10 0x080f36d7 in read_avail_input (expected=1) at /tmp/emacs/src/keyboard.c:7114
> #11 0x080f39fe in handle_async_input () at /tmp/emacs/src/keyboard.c:7340
> #12 0x080f3a31 in input_available_signal (signo=29) at /tmp/emacs/src/keyboard.c:7382
> #13 <signal handler called>
> #14 0x00110402 in __kernel_vsyscall ()
> #15 0x007eb5bd in ___newselect_nocancel () from /lib/libc.so.6
> #16 0x0817440d in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137504121, 
>     wait_proc=0x0, just_wait_proc=0) at /tmp/emacs/src/process.c:4586
> #17 0x08057299 in sit_for (timeout=240, reading=1, do_display=1) at /tmp/emacs/src/dispnew.c:6608
> #18 0x080ef072 in read_char (commandflag=1, nmaps=2, maps=0xbf9f3830, prev_event=137504121, used_mouse_menu=0xbf9f3858, 
>     end_time=0x0) at /tmp/emacs/src/keyboard.c:2969
> #19 0x080f6082 in read_key_sequence (keybuf=0xbf9f39a0, bufsize=30, prompt=137504121, dont_downcase_last=0, 
>     can_return_switch_frame=1, fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:9459
> #20 0x080eccf8 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1655
> #21 0x08147d96 in internal_condition_case (bfun=0x80eca38 <command_loop_1>, handlers=137548353, hfun=0x80ec504 <cmd_error>)
>     at /tmp/emacs/src/eval.c:1494
> #22 0x080ec7d6 in command_loop_2 () at /tmp/emacs/src/keyboard.c:1370
> #23 0x08147907 in internal_catch (tag=137543201, func=0x80ec7b8 <command_loop_2>, arg=137504121)
>     at /tmp/emacs/src/eval.c:1230
> #24 0x080ec764 in command_loop () at /tmp/emacs/src/keyboard.c:1349
> #25 0x080ec188 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:958
> #26 0x080ec2c8 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1020
> #27 0x080eb15b in main (argc=5, argv=0xbf9f3f94) at /tmp/emacs/src/emacs.c:1786

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> > emacs -Q -nw -f server-start
  > >> 
  > >> > emacsclient -c -d $DISPLAY&
  > >> 
  > >> > xkill 
  > >> > the emacsclient X11 frame
  > >> 
  > >> > then C-x C-c in the emacs -nw frame will warn about clients still being
  > >> > connected.
  > >> 
  > >> I installed a patch which refines Richard's fix and brings back the
  > >> correct "close the client connection" when you close a frame by sending
  > >> an X11 "delete" message.  This doesn't solve the above problem because
  > >> in that case, the "delete_frame" execution is run at a time where Elisp
  > >> cannot be executed.
  > 
  > > Now emacs aborts after emacsclient is xkilled.
  > 
  > There was a trivial typo in my first commit, which I fixed in
  > a subsequent commit.  You may just have checked it out between the two.
  > I don't see any crashes here, so please try again,

Indeed, no crashes now. Thanks!

after-delete-terminal-functions (was: 23.0.60; Emacs should survive a lost X connection)

[Stefan Monnier]

> emacs -Q -nw -f server-start

> emacsclient -c -d $DISPLAY&

> xkill 
> the emacsclient X11 frame

> then C-x C-c in the emacs -nw frame will warn about clients still being
> connected.

> Same thing when instead of using xkill, kill X11.

So I looked at the issue of letting know server.el when an X11
connection is abruptly closed as above.

I created a new event DELETE_TERMINAL_EVENT;
changed Fdelete_terminal to generate such an event;
changed x_connection_closed to call Fdelete_terminal

and ... it didn't work.  The problem is that x_connection_closed ends up
signalling an error, which flushes the input queue and hence throws away
the DELETE_TERMINAL_EVENT we just created.

So, I removed the `error' call, but this makes things worse, apparently:
Emacs then exits abruptly.  It seems that it's important to abort
execution at the end of x_connection_closed.  So I re[placed the `error'
call by a call to Fthrow.  This finally worked.

But now I wonder: is DELETE_TERMINAL_EVENT the right thing to do, or
should we use run-at-time instead?

Find attach my current attempt,


        Stefan


? src/.depend
cvs diff: Diffing src
Index: src/keyboard.c
===================================================================
RCS file: /sources/emacs/emacs/src/keyboard.c,v
retrieving revision 1.946
diff -u -r1.946 keyboard.c
--- src/keyboard.c	12 Feb 2008 04:05:29 -0000	1.946
+++ src/keyboard.c	13 Feb 2008 03:06:48 -0000
@@ -466,6 +466,7 @@
 Lisp_Object Qscroll_bar_movement;
 Lisp_Object Qswitch_frame;
 Lisp_Object Qdelete_frame;
+Lisp_Object Qdelete_terminal;
 Lisp_Object Qiconify_frame;
 Lisp_Object Qmake_frame_visible;
 Lisp_Object Qselect_window;
@@ -4195,6 +4196,11 @@
 	  kbd_fetch_ptr = event + 1;
 	}
 #endif
+      else if (event->kind == DELETE_TERMINAL_EVENT)
+	{
+	  obj = Fcons (Qdelete_terminal, Fcons (event->frame_or_window, Qnil));
+	  kbd_fetch_ptr = event + 1;
+	}
 #if defined (HAVE_X11) || defined (HAVE_NTGUI) || defined (MAC_OS)
       else if (event->kind == ICONIFY_EVENT)
 	{
@@ -11718,6 +11724,7 @@
   {&Qscroll_bar_movement, "scroll-bar-movement", &Qmouse_movement},
   {&Qswitch_frame,        "switch-frame",        &Qswitch_frame},
   {&Qdelete_frame,        "delete-frame",        &Qdelete_frame},
+  {&Qdelete_terminal,     "delete-terminal",     &Qdelete_terminal},
   {&Qiconify_frame,       "iconify-frame",       &Qiconify_frame},
   {&Qmake_frame_visible,  "make-frame-visible",  &Qmake_frame_visible},
   /* `select-window' should be handled just like `switch-frame'
Index: src/lisp.h
===================================================================
RCS file: /sources/emacs/emacs/src/lisp.h,v
retrieving revision 1.611
diff -u -r1.611 lisp.h
--- src/lisp.h	12 Feb 2008 21:35:14 -0000	1.611
+++ src/lisp.h	13 Feb 2008 03:06:49 -0000
@@ -3261,6 +3261,7 @@
 extern void fatal P_ ((const char *msgid, ...)) NO_RETURN;
 
 /* Defined in terminal.c */
+EXFUN (Fdelete_terminal, 2);
 extern void syms_of_terminal P_ ((void));
 
 #ifdef HAVE_WINDOW_SYSTEM
Index: src/puresize.h
===================================================================
RCS file: /sources/emacs/emacs/src/puresize.h,v
retrieving revision 1.104
diff -u -r1.104 puresize.h
--- src/puresize.h	1 Feb 2008 23:29:14 -0000	1.104
+++ src/puresize.h	13 Feb 2008 03:06:49 -0000
@@ -35,7 +35,7 @@
    amount of storage.  This is a lot more update-robust that defining
    BASE_PURESIZE or even PURESIZE directly.  */
 #ifndef SYSTEM_PURESIZE_EXTRA
-#define SYSTEM_PURESIZE_EXTRA 0
+#define SYSTEM_PURESIZE_EXTRA 1000000
 #endif
 
 #ifndef SITELOAD_PURESIZE_EXTRA
Index: src/termhooks.h
===================================================================
RCS file: /sources/emacs/emacs/src/termhooks.h,v
retrieving revision 1.91
diff -u -r1.91 termhooks.h
--- src/termhooks.h	8 Jan 2008 20:44:20 -0000	1.91
+++ src/termhooks.h	13 Feb 2008 03:06:49 -0000
@@ -137,6 +137,7 @@
   SELECTION_CLEAR_EVENT,	/* Another X client cleared our selection.  */
   BUFFER_SWITCH_EVENT,		/* A process filter has switched buffers.  */
   DELETE_WINDOW_EVENT,		/* An X client said "delete this window".  */
+  DELETE_TERMINAL_EVENT,        /* A terminal was deleted.  */
   MENU_BAR_EVENT,		/* An event generated by the menu bar.
 				   The frame_or_window field's cdr holds the
 				   Lisp-level event value.
Index: src/terminal.c
===================================================================
RCS file: /sources/emacs/emacs/src/terminal.c,v
retrieving revision 1.9
diff -u -r1.9 terminal.c
--- src/terminal.c	11 Feb 2008 03:51:39 -0000	1.9
+++ src/terminal.c	13 Feb 2008 03:06:49 -0000
@@ -320,6 +320,15 @@
 	error ("Attempt to delete the sole active display terminal");
     }
 
+  if (!NILP (Vrun_hooks))
+    {
+      struct input_event ie;
+      ie.kind = DELETE_TERMINAL_EVENT;
+      ie.arg = Qnil;
+      XSETTERMINAL (ie.frame_or_window, t);
+      kbd_buffer_store_event (&ie);
+    }
+
   if (t->delete_terminal_hook)
     (*t->delete_terminal_hook) (t);
   else
Index: src/xterm.c
===================================================================
RCS file: /sources/emacs/emacs/src/xterm.c,v
retrieving revision 1.975
diff -u -r1.975 xterm.c
--- src/xterm.c	10 Feb 2008 21:56:37 -0000	1.975
+++ src/xterm.c	13 Feb 2008 03:06:50 -0000
@@ -8093,10 +8093,11 @@
      OpenWindows in certain situations.  I suspect that is a bug
      in OpenWindows.  I don't know how to circumvent it here.  */
 
+  if (dpyinfo)
+    {
 #ifdef USE_X_TOOLKIT
   /* If DPYINFO is null, this means we didn't open the display
      in the first place, so don't try to close it.  */
-  if (dpyinfo)
     {
       extern void (*fatal_error_signal_hook) P_ ((void));
       fatal_error_signal_hook = x_fatal_error_signal;
@@ -8106,12 +8107,9 @@
 #endif
 
 #ifdef USE_GTK
-  if (dpyinfo)
     xg_display_close (dpyinfo->display);
 #endif
 
-  if (dpyinfo)
-    {
       /* Indicate that this display is dead.  */
       dpyinfo->display = 0;
 
@@ -8121,7 +8119,14 @@
         /* We have just closed all frames on this display. */
         abort ();
 
-      x_delete_display (dpyinfo);
+      {
+	struct terminal *t = terminal_list;
+	Lisp_Object tmp;
+	while (t && t->display_info.x != dpyinfo)
+	  t = t->next_terminal;
+	XSETTERMINAL (tmp, t);
+	Fdelete_terminal (tmp, Qnoelisp);
+      }
     }
 
   x_uncatch_errors ();
@@ -8146,7 +8151,10 @@
      error might not be the best thing to do.  I'd vote for creating an
      elisp event and stuffing it in the queue so people can bind to it via
      the global map.  --Stef  */
-  error ("%s", error_msg);
+  /* We used to throw an error, but this flushes the input_event queue,
+     on which we just put a DELETE_TERMINAL_EVENT :-(
+     error ("%s", error_msg) */
+  Fthrow (Qtop_level, Qnil);
 }
 
 /* We specifically use it before defining it, so that gcc doesn't inline it,
@@ -11812,6 +11812,10 @@
     return;
 
   BLOCK_INPUT;
+  /* When called from x_connection_closed, the display is already closed
+     and dpyinfo->display was set to 0 to indicate that.  */
+  if (dpyinfo->display)
+    {
 #ifdef USE_FONT_BACKEND
   if (! enable_font_backend)
 #endif
@@ -11834,6 +11838,7 @@
   XCloseDisplay (dpyinfo->display);
 #endif
 #endif /* ! USE_GTK */
+    }
 
   x_delete_display (dpyinfo);
   UNBLOCK_INPUT;
cvs diff: Diffing src/bitmaps
cvs diff: Diffing src/m
cvs diff: Diffing src/s

Re: after-delete-terminal-functions (was: 23.0.60; Emacs should survive a lost X connection)

[Richard Stallman]

    But now I wonder: is DELETE_TERMINAL_EVENT the right thing to do, or
    should we use run-at-time instead?

I don't see any reason why run-at-time would work better,
and it certainly is not cleaner.  It is less clean.

    So, I removed the `error' call, but this makes things worse, apparently:
    Emacs then exits abruptly.  It seems that it's important to abort
    execution at the end of x_connection_closed.  So I re[placed the `error'
    call by a call to Fthrow.  This finally worked.

That seems like a plausible approach to me.

However, another idea is to signal an error and do something special
so that this error doesn't clear the event.  Even better, the
top-level loop could queue the event after catching this kind of
error.

Or the top-level loop could call the appropriate hook after catching
this kind of error.  That way there would be no event, just a hook.

It could distinguish this error based on an error condition symbol.
That would be clean.

Re: after-delete-terminal-functions

[Stefan Monnier]

>     But now I wonder: is DELETE_TERMINAL_EVENT the right thing to do, or
>     should we use run-at-time instead?

> I don't see any reason why run-at-time would work better,
> and it certainly is not cleaner.  It is less clean.

>     So, I removed the `error' call, but this makes things worse, apparently:
>     Emacs then exits abruptly.  It seems that it's important to abort
>     execution at the end of x_connection_closed.  So I re[placed the `error'
>     call by a call to Fthrow.  This finally worked.

> That seems like a plausible approach to me.

> However, another idea is to signal an error and do something special
> so that this error doesn't clear the event.  Even better, the
> top-level loop could queue the event after catching this kind of
> error.

> Or the top-level loop could call the appropriate hook after catching
> this kind of error.  That way there would be no event, just a hook.

> It could distinguish this error based on an error condition symbol.
> That would be clean.

That's an option, indeed.  The problem is that the hook needs to be run
in various circumstances:
- when the terminal is killed explicitly via delete-terminal.
- when the terminal is killed via delete-frame.
- when the terminal is killed from keyboard.c noticing that the `read' fails.
- when the terminal is killed because of the x_io_error.

So it is cleaner to put the "run the hook" in Fdelete_terminal which is
pretty much the common path of all 4.  But sometimes Fdelete_terminal
cannot run elisp, hence the idea of creating an event.

Maybe an alternative is to add a variable `delayed_evals' which would
hold a list of things to run "ASAP".


        Stefan

Re: after-delete-terminal-functions

[Richard Stallman]

    So it is cleaner to put the "run the hook" in Fdelete_terminal which is
    pretty much the common path of all 4.  But sometimes Fdelete_terminal
    cannot run elisp, hence the idea of creating an event.

It could be run from Fdelete_terminal when possible, and it could be
run as I suggested in the case of losing an X connection.

Re: after-delete-terminal-functions

[Stefan Monnier]

>     So it is cleaner to put the "run the hook" in Fdelete_terminal which is
>     pretty much the common path of all 4.  But sometimes Fdelete_terminal
>     cannot run elisp, hence the idea of creating an event.

> It could be run from Fdelete_terminal when possible, and it could be
> run as I suggested in the case of losing an X connection.

I've solved it differently.


        Stefan

Re: 23.0.60; Emacs should survive a lost X connection

[Richard Stallman]

    No, the emacs server keeps track of the number of emacsclients that are
    still connected, when that number is > 0 and you are doing C-x C-c it
    will warn that emacsclients are still connected 
    (see server-kill-emacs-query-function)

    In the case described here, there are no emacsclients that are still
    connected (they have died when X has died, or have been killed with
    xkill), but the server thinks otherwise.

Losing connection with the X server
has nothing to do with emacsclient.
You can't assume that an emacsclient process is dead
just because of losing contact with an X server.
You can't even assume this if they are on the same machine.

If there is a problem in dealing with loss of connection
to emacsclient, that's a separate issue.

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     No, the emacs server keeps track of the number of emacsclients that are
  >     still connected, when that number is > 0 and you are doing C-x C-c it
  >     will warn that emacsclients are still connected 
  >     (see server-kill-emacs-query-function)
  > 
  >     In the case described here, there are no emacsclients that are still
  >     connected (they have died when X has died, or have been killed with
  >     xkill), but the server thinks otherwise.
  > 
  > Losing connection with the X server
  > has nothing to do with emacsclient.
  > You can't assume that an emacsclient process is dead
  > just because of losing contact with an X server.
  > You can't even assume this if they are on the same machine.

In this particular case emacsclient is dead.

Re: 23.0.60; Emacs should survive a lost X connection

[Stefan Monnier]

>> No, the emacs server keeps track of the number of emacsclients that are
>> still connected, when that number is > 0 and you are doing C-x C-c it
>> will warn that emacsclients are still connected 
>> (see server-kill-emacs-query-function)
>> 
>> In the case described here, there are no emacsclients that are still
>> connected (they have died when X has died, or have been killed with
>> xkill), but the server thinks otherwise.
>> 
>> Losing connection with the X server
>> has nothing to do with emacsclient.
>> You can't assume that an emacsclient process is dead
>> just because of losing contact with an X server.
>> You can't even assume this if they are on the same machine.

> In this particular case emacsclient is dead.

Yes, but the bug has nothing to do directly with killing the Xserver
(tho maybe it's the only way to trigger it ;-).


        Stefan

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: rms@gnu.org.  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 <rms@gnu.org>:

> 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

Re: 23.0.60; Emacs should survive a lost X connection

[Miles Bader]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
> For some reason, rms is sending out his messages on this thread with
> Reply-to: rms@gnu.org.  So I had sent the reply below to him only.

The Reply-To: header shouldn't affect followups, wide-replies, and other
normal ways of replying to the list.

-Miles

-- 
Alone, adj. In bad company.

Re: 23.0.60; Emacs should survive a lost X connection

[Harald Hanche-Olsen]

+ Miles Bader <miles@gnu.org>:

> Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
> > For some reason, rms is sending out his messages on this thread with
> > Reply-to: rms@gnu.org.  So I had sent the reply below to him only.
> 
> The Reply-To: header shouldn't affect followups, wide-replies, and
> other normal ways of replying to the list.

Okay, thanks for the tip.  I need to go through my mail setup a bit,
as this is not the first time I'm bitten by this. (I use mew, which
does not seem to have a concept of followup, just reply.)

- Harald

Re: 23.0.60; Emacs should survive a lost X connection

[Miles Bader]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
> (I use mew, which does not seem to have a concept of followup, just
> reply.)

That's extremely odd for a capable MUA, as such a command is
indispensable for reading mailing lists.  Are you sure it doesn't have
it under a different name ("wide reply", "reply to ...", etc)?

-Miles

-- 
Guilt, n. The condition of one who is known to have committed an indiscretion,
as distinguished from the state of him who has covered his tracks.

Re: 23.0.60; Emacs should survive a lost X connection

[Harald Hanche-Olsen]

+ Miles Bader <miles@gnu.org>:

> Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
> > (I use mew, which does not seem to have a concept of followup, just
> > reply.)
> 
> That's extremely odd for a capable MUA, as such a command is
> indispensable for reading mailing lists.  Are you sure it doesn't have
> it under a different name ("wide reply", "reply to ...", etc)?

Ah, you're right.  The default action is the wide reply, while with
C-u it replies to sender only.  In either case, it treats the Reply-To
header as an extra address to send the reply to.  I am the one guilty
of changing this behaviour (so long ago I had forgotten about it).  I
probably did so from a misunderstanding of what the reply-to field
means, as a rather strong indication that replies are to be sent to
the indicated address only.  But RFC 2822 seems to say otherwise.
Time to revert my mew setup to the default, then.

> Guilt, n. The condition of one who is known to have committed an
> indiscretion, as distinguished from the state of him who has covered
> his tracks.

How appropriate.  8-)

- Harald

Re: 23.0.60; Emacs should survive a lost X connection

[Richard Stallman]

[ The consequences of my mistake in responding to RMS accumulate, as
  he responded back just to me.  I am sure his response was intended
  for the list, so here it, just as I received it. - Harald ]

    #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

This means that control got back to command_loop and x_catching_errors
was still true.  That should never happen.  I would guess that it happens
because an error is signaled while x_catching_errors is true.

I don't see how my two changes could cause this to happen
if it didn't happen anyway.

One was the error check, which is being hit in your new case
because something is already truly wrong, but which cannot
cause it to become wrong.

The other, in Fdelete_frame, was to avoid running a hook and thus
avoid calling internal_condition_case there.  I don't see any way that
could cause this problem, unless I made a stupid error there which I
don't see.  Can someone else see one?  Can you put a breakpoint
at this recursive call to Fdelete_frame and see if it occurs?

	      /* If we MUST delete this frame, delete the other first.  */
	      if (!NILP (force))
		Fdelete_frame (this, force);


In any case, I think the following fix is called for.  It reenables
the automatic clearing of x error catching, whose validity is assured
by the error check that I reenabled.  Does this give you correct
behavior?


*** eval.c	07 Feb 2008 21:30:57 -0500	1.298
--- eval.c	10 Feb 2008 08:13:09 -0500	
***************
*** 1281,1292 ****
  #if HAVE_X_WINDOWS
    /* If x_catch_errors was done, turn it off now.
       (First we give unbind_to a chance to do that.)  */
! #if 0 /* This would disable x_catch_errors after x_connection_closed.
!        * The catch must remain in effect during that delicate
!        * state. --lorentey  */
    x_fully_uncatch_errors ();
  #endif
- #endif
  
    byte_stack_list = catch->byte_stack;
    gcprolist = catch->gcpro;
--- 1281,1293 ----
  #if HAVE_X_WINDOWS
    /* If x_catch_errors was done, turn it off now.
       (First we give unbind_to a chance to do that.)  */
!   /* This was disabled by lorentey, saying
!      "This would disable x_catch_errors after x_connection_closed.
!       The catch must remain in effect during that delicate state."
!       However, errors need to clear this out
!       to avoid the bug reported by hanche@math.ntnu.no on 8 feb 2008.  */
    x_fully_uncatch_errors ();
  #endif
  
    byte_stack_list = catch->byte_stack;
    gcprolist = catch->gcpro;

Re: 23.0.60; Emacs should survive a lost X connection

[Harald Hanche-Olsen]

+ Richard Stallman <rms@gnu.org>:

> In any case, I think the following fix is called for.  It reenables
> the automatic clearing of x error catching, whose validity is assured
> by the error check that I reenabled.  Does this give you correct
> behavior?

I need to be in my office to test this, so it will have to wait until
tomorrow.  I'll get back with an answer then.

As for the breakpoint you wanted me to try, I will try it, but as I
have gotten different behaviours when running under gdb it's not clear
that it will accomplish anything.

- Harald

Re: 23.0.60; Emacs should survive a lost X connection

[Leo]

On 2008-02-10 19:44 +0000, Harald Hanche-Olsen wrote:
> + Richard Stallman <rms@gnu.org>:
>
>> In any case, I think the following fix is called for.  It reenables
>> the automatic clearing of x error catching, whose validity is assured
>> by the error check that I reenabled.  Does this give you correct
>> behavior?
>
> I need to be in my office to test this, so it will have to wait until
> tomorrow.  I'll get back with an answer then.
>
> As for the breakpoint you wanted me to try, I will try it, but as I
> have gotten different behaviours when running under gdb it's not clear
> that it will accomplish anything.
>
> - Harald

With CVS 20080210 I am still seeing a bug that can be reproduced this
way:

  1.  emacs -q -nw -f server-start
  2.  emacsclient -c ;; open a X frame
  3.  C-x 5 0 to close the X frame
  4.  Try `emacsclient -c' a second time
  5.  Fatal error

,----
| Waiting for Emacs...
| *ERROR*: Arithmetic error
`----

HTH,
-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: 23.0.60; Emacs should survive a lost X connection

[Dan Nicolaescu]

Leo <sdl.web@gmail.com> writes:

  > On 2008-02-10 19:44 +0000, Harald Hanche-Olsen wrote:
  > > + Richard Stallman <rms@gnu.org>:
  > >
  > >> In any case, I think the following fix is called for.  It reenables
  > >> the automatic clearing of x error catching, whose validity is assured
  > >> by the error check that I reenabled.  Does this give you correct
  > >> behavior?
  > >
  > > I need to be in my office to test this, so it will have to wait until
  > > tomorrow.  I'll get back with an answer then.
  > >
  > > As for the breakpoint you wanted me to try, I will try it, but as I
  > > have gotten different behaviours when running under gdb it's not clear
  > > that it will accomplish anything.
  > >
  > > - Harald
  > 
  > With CVS 20080210 I am still seeing a bug that can be reproduced this
  > way:
  > 
  >   1.  emacs -q -nw -f server-start
  >   2.  emacsclient -c ;; open a X frame
  >   3.  C-x 5 0 to close the X frame
  >   4.  Try `emacsclient -c' a second time
  >   5.  Fatal error

Is that with --enable-font-backend? 
If so, then it's a different problem.
See the tread with the subject:
"--enable-font-backend bug (was: Re: 23.0.60;   emacs segfaults when creating X display via ...."

Re: 23.0.60; Emacs should survive a lost X connection

[Leo]

On 2008-02-10 23:26 +0000, Dan Nicolaescu wrote:
> Is that with --enable-font-backend? 
> If so, then it's a different problem.
> See the tread with the subject:
> "--enable-font-backend bug (was: Re: 23.0.60;   emacs segfaults when creating X display via ...."

Thanks, but there is no fix yet.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: 23.0.60; Emacs should survive a lost X connection

[Richard Stallman]

    With CVS 20080210 I am still seeing a bug that can be reproduced this
    way:

      1.  emacs -q -nw -f server-start
      2.  emacsclient -c ;; open a X frame
      3.  C-x 5 0 to close the X frame
      4.  Try `emacsclient -c' a second time
      5.  Fatal error

Does my recent eval.c patch help?  (It is not installed.)

Re: 23.0.60; Emacs should survive a lost X connection

[Leo]

On 2008-02-11 13:34 +0000, Richard Stallman wrote:
>     With CVS 20080210 I am still seeing a bug that can be reproduced this
>     way:
>
>       1.  emacs -q -nw -f server-start
>       2.  emacsclient -c ;; open a X frame
>       3.  C-x 5 0 to close the X frame
>       4.  Try `emacsclient -c' a second time
>       5.  Fatal error
>
> Does my recent eval.c patch help?  (It is not installed.)

Could someone test the patch? I cannot access my build machine on week
days.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: 23.0.60; Emacs should survive a lost X connection

[Richard Stallman]

    #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

This means that control got back to command_loop and x_catching_errors
was still true.  That should never happen.  I would guess that it happens
because an error is signaled while x_catching_errors is true.

I don't see how my two changes could cause this to happen
if it didn't happen anyway.

One was the error check, which is being hit in your new case
because something is already truly wrong, but which cannot
cause it to become wrong.

The other, in Fdelete_frame, was to avoid running a hook and thus
avoid calling internal_condition_case there.  I don't see any way that
could cause this problem, unless I made a stupid error there which I
don't see.  Can someone else see one?  Can you put a breakpoint
at this recursive call to Fdelete_frame and see if it occurs?

	      /* If we MUST delete this frame, delete the other first.  */
	      if (!NILP (force))
		Fdelete_frame (this, force);


In any case, I think the following fix is called for.  It reenables
the automatic clearing of x error catching, whose validity is assured
by the error check that I reenabled.  Does this give you correct
behavior?


*** eval.c	07 Feb 2008 21:30:57 -0500	1.298
--- eval.c	10 Feb 2008 08:13:09 -0500	
***************
*** 1281,1292 ****
  #if HAVE_X_WINDOWS
    /* If x_catch_errors was done, turn it off now.
       (First we give unbind_to a chance to do that.)  */
! #if 0 /* This would disable x_catch_errors after x_connection_closed.
!        * The catch must remain in effect during that delicate
!        * state. --lorentey  */
    x_fully_uncatch_errors ();
  #endif
- #endif
  
    byte_stack_list = catch->byte_stack;
    gcprolist = catch->gcpro;
--- 1281,1293 ----
  #if HAVE_X_WINDOWS
    /* If x_catch_errors was done, turn it off now.
       (First we give unbind_to a chance to do that.)  */
!   /* This was disabled by lorentey, saying
!      "This would disable x_catch_errors after x_connection_closed.
!       The catch must remain in effect during that delicate state."
!       However, errors need to clear this out
!       to avoid the bug reported by hanche@math.ntnu.no on 8 feb 2008.  */
    x_fully_uncatch_errors ();
  #endif
  
    byte_stack_list = catch->byte_stack;
    gcprolist = catch->gcpro;

Re: 23.0.60; Emacs should survive a lost X connection

[Harald Hanche-Olsen]

+ Richard Stallman <rms@gnu.org>:

> Can someone else see one?  Can you put a breakpoint
> at this recursive call to Fdelete_frame and see if it occurs?
> 
> 	      /* If we MUST delete this frame, delete the other first.  */
> 	      if (!NILP (force))
> 		Fdelete_frame (this, force);

Done.  It never happens in my test.  By the way, I reported that I
don't see a problem (or much of one) if gdb is attached to emacs.
However, I now think this was because gdb would break program
execution when a SIGPIPE was received:  If I tell gdb not to stop at a
SIGPIPE, I get the abort as before:

(gdb) handle SIGPIPE nostop
Signal        Stop      Print   Pass to program Description
SIGPIPE       No        Yes     Yes             Broken pipe
(gdb) break frame.c:1401
Breakpoint 1 at 0x806051e: file frame.c, line 1401.
(gdb) c
Continuing.

Program received signal SIGPIPE, Broken pipe.

Program received signal SIGABRT, Aborted.
0x88cb9ecb in kill () from /lib/libc.so.6
(gdb) back
#0  0x88cb9ecb in kill () from /lib/libc.so.6
#1  0x0811e2b2 in abort () at emacs.c:433
#2  0x08180e2f in internal_condition_case (bfun=0x812ceb4 <command_loop_1>, 
    handlers=137829497, hfun=0x8126584 <cmd_error>) at eval.c:1469
#3  0x08120736 in command_loop_2 () at keyboard.c:1370
#4  0x08180b3d in internal_catch (tag=0, func=0x8120718 <command_loop_2>, 
    arg=137779201) at eval.c:1230
#5  0x08120548 in command_loop () at keyboard.c:1349
#6  0x081205e4 in recursive_edit_1 () at keyboard.c:958
#7  0x08120703 in Frecursive_edit () at keyboard.c:1020
#8  0x0811f9ba in main (argc=3, argv=0xbfbfadec) at emacs.c:1794
(gdb) 

> In any case, I think the following fix is called for.  It reenables
> the automatic clearing of x error catching, whose validity is assured
> by the error check that I reenabled.  Does this give you correct
> behavior?

Then I can't even compile emacs, as there is no x_fully_uncatch_errors
that I (or gcc) is able to find.

- Harald