all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 23.0.60; Emacs should survive a lost X connection
@ 2008-02-05 14:58 Harald Hanche-Olsen
  2008-02-05 19:57 ` Dan Nicolaescu
  0 siblings, 1 reply; 37+ messages in thread
From: Harald Hanche-Olsen @ 2008-02-05 14:58 UTC (permalink / raw)
  To: emacs-pretest-bug

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* 23.0.60; Emacs should survive a lost X connection
@ 2008-02-05 16:55 Harald Hanche-Olsen
  2008-02-10 21:02 ` Harald Hanche-Olsen
  0 siblings, 1 reply; 37+ messages in thread
From: Harald Hanche-Olsen @ 2008-02-05 16:55 UTC (permalink / raw)
  To: bug-gnu-emacs

I sent this first to emacs-pretest-bug@gnu.org, but then I went to
check the archives at lists.gnu.org and found that emacs-pretest-bug
appears to be defunct?  And yet, that is where M-x report-emacs-bug
wants to send bug reports.  A bug report addressing bug?

Now to the bug report itself:

----------------

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-05 14:58 Harald Hanche-Olsen
@ 2008-02-05 19:57 ` Dan Nicolaescu
  2008-02-05 20:39   ` Harald Hanche-Olsen
  2008-02-05 23:49   ` Dan Nicolaescu
  0 siblings, 2 replies; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-05 19:57 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-pretest-bug

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-05 19:57 ` Dan Nicolaescu
@ 2008-02-05 20:39   ` Harald Hanche-Olsen
  2008-02-05 23:49   ` Dan Nicolaescu
  1 sibling, 0 replies; 37+ messages in thread
From: Harald Hanche-Olsen @ 2008-02-05 20:39 UTC (permalink / raw)
  To: dann; +Cc: emacs-pretest-bug

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-05 19:57 ` Dan Nicolaescu
  2008-02-05 20:39   ` Harald Hanche-Olsen
@ 2008-02-05 23:49   ` Dan Nicolaescu
  2008-02-06 19:20     ` Richard Stallman
  1 sibling, 1 reply; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-05 23:49 UTC (permalink / raw)
  To: Richard Stallman; +Cc: emacs-pretest-bug, Harald Hanche-Olsen

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).




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-05 23:49   ` Dan Nicolaescu
@ 2008-02-06 19:20     ` Richard Stallman
  2008-02-06 20:07       ` Dan Nicolaescu
  0 siblings, 1 reply; 37+ messages in thread
From: Richard Stallman @ 2008-02-06 19:20 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, hanche

		* 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.





^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-06 19:20     ` Richard Stallman
@ 2008-02-06 20:07       ` Dan Nicolaescu
  2008-02-08  4:16         ` Richard Stallman
  0 siblings, 1 reply; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-06 20:07 UTC (permalink / raw)
  To: rms; +Cc: emacs-pretest-bug, hanche

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).





^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-06 20:07       ` Dan Nicolaescu
@ 2008-02-08  4:16         ` Richard Stallman
  2008-02-08  7:26           ` Dan Nicolaescu
                             ` (2 more replies)
  0 siblings, 3 replies; 37+ messages in thread
From: Richard Stallman @ 2008-02-08  4:16 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, hanche

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?




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-08  4:16         ` Richard Stallman
@ 2008-02-08  7:26           ` Dan Nicolaescu
  2008-02-09  4:52             ` Richard Stallman
  2008-02-10  8:27           ` Harald Hanche-Olsen
       [not found]           ` <20080208.195113.190255739.hanche@math.ntnu.no>
  2 siblings, 1 reply; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-08  7:26 UTC (permalink / raw)
  To: rms; +Cc: emacs-pretest-bug, hanche

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.




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-08  7:26           ` Dan Nicolaescu
@ 2008-02-09  4:52             ` Richard Stallman
  2008-02-09  5:04               ` Dan Nicolaescu
  0 siblings, 1 reply; 37+ messages in thread
From: Richard Stallman @ 2008-02-09  4:52 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, hanche

    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?




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-09  4:52             ` Richard Stallman
@ 2008-02-09  5:04               ` Dan Nicolaescu
  2008-02-10  3:10                 ` Stefan Monnier
  2008-02-10  3:20                 ` Richard Stallman
  0 siblings, 2 replies; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-09  5:04 UTC (permalink / raw)
  To: rms; +Cc: emacs-pretest-bug, hanche

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.




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-09  5:04               ` Dan Nicolaescu
@ 2008-02-10  3:10                 ` Stefan Monnier
  2008-02-10  8:03                   ` Dan Nicolaescu
  2008-02-10  3:20                 ` Richard Stallman
  1 sibling, 1 reply; 37+ messages in thread
From: Stefan Monnier @ 2008-02-10  3:10 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, hanche, rms

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-09  5:04               ` Dan Nicolaescu
  2008-02-10  3:10                 ` Stefan Monnier
@ 2008-02-10  3:20                 ` Richard Stallman
  2008-02-10  8:03                   ` Dan Nicolaescu
  1 sibling, 1 reply; 37+ messages in thread
From: Richard Stallman @ 2008-02-10  3:20 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, hanche

    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.





^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10  3:10                 ` Stefan Monnier
@ 2008-02-10  8:03                   ` Dan Nicolaescu
  2008-02-10 20:26                     ` Stefan Monnier
  2008-02-10 22:08                     ` Stefan Monnier
  0 siblings, 2 replies; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-10  8:03 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-pretest-bug, hanche, rms

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.




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10  3:20                 ` Richard Stallman
@ 2008-02-10  8:03                   ` Dan Nicolaescu
  2008-02-10 15:36                     ` Stefan Monnier
  0 siblings, 1 reply; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-10  8:03 UTC (permalink / raw)
  To: rms; +Cc: emacs-pretest-bug, hanche

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.





^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-08  4:16         ` Richard Stallman
  2008-02-08  7:26           ` Dan Nicolaescu
@ 2008-02-10  8:27           ` Harald Hanche-Olsen
  2008-02-10  8:58             ` Miles Bader
       [not found]           ` <20080208.195113.190255739.hanche@math.ntnu.no>
  2 siblings, 1 reply; 37+ messages in thread
From: Harald Hanche-Olsen @ 2008-02-10  8:27 UTC (permalink / raw)
  To: emacs-pretest-bug; +Cc: dann

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10  8:27           ` Harald Hanche-Olsen
@ 2008-02-10  8:58             ` Miles Bader
  2008-02-10  9:34               ` Harald Hanche-Olsen
  0 siblings, 1 reply; 37+ messages in thread
From: Miles Bader @ 2008-02-10  8:58 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-pretest-bug, dann

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.




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10  8:58             ` Miles Bader
@ 2008-02-10  9:34               ` Harald Hanche-Olsen
  2008-02-10 13:19                 ` Miles Bader
  0 siblings, 1 reply; 37+ messages in thread
From: Harald Hanche-Olsen @ 2008-02-10  9:34 UTC (permalink / raw)
  To: miles; +Cc: emacs-pretest-bug, dann

+ 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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10  9:34               ` Harald Hanche-Olsen
@ 2008-02-10 13:19                 ` Miles Bader
  2008-02-10 16:55                   ` Harald Hanche-Olsen
  0 siblings, 1 reply; 37+ messages in thread
From: Miles Bader @ 2008-02-10 13:19 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-pretest-bug, dann

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.




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10  8:03                   ` Dan Nicolaescu
@ 2008-02-10 15:36                     ` Stefan Monnier
  0 siblings, 0 replies; 37+ messages in thread
From: Stefan Monnier @ 2008-02-10 15:36 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, hanche, rms

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10 13:19                 ` Miles Bader
@ 2008-02-10 16:55                   ` Harald Hanche-Olsen
  0 siblings, 0 replies; 37+ messages in thread
From: Harald Hanche-Olsen @ 2008-02-10 16:55 UTC (permalink / raw)
  To: miles; +Cc: emacs-pretest-bug

+ 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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
       [not found]           ` <20080208.195113.190255739.hanche@math.ntnu.no>
@ 2008-02-10 19:04             ` Richard Stallman
  2008-02-10 19:44               ` Harald Hanche-Olsen
  2008-02-11  0:17             ` Richard Stallman
  1 sibling, 1 reply; 37+ messages in thread
From: Richard Stallman @ 2008-02-10 19:04 UTC (permalink / raw)
  To: emacs-pretest-bug

[ 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;




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10 19:04             ` Richard Stallman
@ 2008-02-10 19:44               ` Harald Hanche-Olsen
  2008-02-10 22:09                 ` Leo
  0 siblings, 1 reply; 37+ messages in thread
From: Harald Hanche-Olsen @ 2008-02-10 19:44 UTC (permalink / raw)
  To: rms; +Cc: emacs-pretest-bug

+ 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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10  8:03                   ` Dan Nicolaescu
@ 2008-02-10 20:26                     ` Stefan Monnier
  2008-02-11 13:35                       ` Richard Stallman
  2008-02-10 22:08                     ` Stefan Monnier
  1 sibling, 1 reply; 37+ messages in thread
From: Stefan Monnier @ 2008-02-10 20:26 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, hanche, rms

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-05 16:55 23.0.60; Emacs should survive a lost X connection Harald Hanche-Olsen
@ 2008-02-10 21:02 ` Harald Hanche-Olsen
  0 siblings, 0 replies; 37+ messages in thread
From: Harald Hanche-Olsen @ 2008-02-10 21:02 UTC (permalink / raw)
  To: bug-gnu-emacs

Regular readers of bug-gnu-emacs can probably skip this: I am writing
this primarily for the benefit of people browsing the list archive.
The bug I reported is being handled over on the emacs-pretest-bug
list, and a solution seems to be forthcoming.  Be patient.

- Harald




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10  8:03                   ` Dan Nicolaescu
  2008-02-10 20:26                     ` Stefan Monnier
@ 2008-02-10 22:08                     ` Stefan Monnier
  2008-02-11  5:34                       ` Dan Nicolaescu
  1 sibling, 1 reply; 37+ messages in thread
From: Stefan Monnier @ 2008-02-10 22:08 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, hanche, rms

> 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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10 19:44               ` Harald Hanche-Olsen
@ 2008-02-10 22:09                 ` Leo
  2008-02-10 23:26                   ` Dan Nicolaescu
  2008-02-11 13:34                   ` Richard Stallman
  0 siblings, 2 replies; 37+ messages in thread
From: Leo @ 2008-02-10 22:09 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-pretest-bug, rms

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/




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10 22:09                 ` Leo
@ 2008-02-10 23:26                   ` Dan Nicolaescu
  2008-02-10 23:38                     ` Leo
  2008-02-11 13:34                   ` Richard Stallman
  1 sibling, 1 reply; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-10 23:26 UTC (permalink / raw)
  To: Leo; +Cc: emacs-pretest-bug, Harald Hanche-Olsen, rms

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 ...."




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10 23:26                   ` Dan Nicolaescu
@ 2008-02-10 23:38                     ` Leo
  0 siblings, 0 replies; 37+ messages in thread
From: Leo @ 2008-02-10 23:38 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, Harald Hanche-Olsen, rms

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/




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
       [not found]           ` <20080208.195113.190255739.hanche@math.ntnu.no>
  2008-02-10 19:04             ` Richard Stallman
@ 2008-02-11  0:17             ` Richard Stallman
  2008-02-11 13:39               ` Harald Hanche-Olsen
  1 sibling, 1 reply; 37+ messages in thread
From: Richard Stallman @ 2008-02-11  0:17 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-devel

    #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;




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10 22:08                     ` Stefan Monnier
@ 2008-02-11  5:34                       ` Dan Nicolaescu
  2008-02-11 14:41                         ` Stefan Monnier
  0 siblings, 1 reply; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-11  5:34 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-pretest-bug, hanche, rms

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10 22:09                 ` Leo
  2008-02-10 23:26                   ` Dan Nicolaescu
@ 2008-02-11 13:34                   ` Richard Stallman
  2008-02-11 23:48                     ` Leo
  1 sibling, 1 reply; 37+ messages in thread
From: Richard Stallman @ 2008-02-11 13:34 UTC (permalink / raw)
  To: Leo; +Cc: emacs-pretest-bug, hanche

    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.)




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-10 20:26                     ` Stefan Monnier
@ 2008-02-11 13:35                       ` Richard Stallman
  0 siblings, 0 replies; 37+ messages in thread
From: Richard Stallman @ 2008-02-11 13:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-pretest-bug, dann, hanche

      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?




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-11  0:17             ` Richard Stallman
@ 2008-02-11 13:39               ` Harald Hanche-Olsen
  0 siblings, 0 replies; 37+ messages in thread
From: Harald Hanche-Olsen @ 2008-02-11 13:39 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

+ 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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-11  5:34                       ` Dan Nicolaescu
@ 2008-02-11 14:41                         ` Stefan Monnier
  2008-02-11 17:16                           ` Dan Nicolaescu
  0 siblings, 1 reply; 37+ messages in thread
From: Stefan Monnier @ 2008-02-11 14:41 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-pretest-bug, hanche, rms

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




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-11 14:41                         ` Stefan Monnier
@ 2008-02-11 17:16                           ` Dan Nicolaescu
  0 siblings, 0 replies; 37+ messages in thread
From: Dan Nicolaescu @ 2008-02-11 17:16 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-pretest-bug, hanche, rms

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!




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: 23.0.60; Emacs should survive a lost X connection
  2008-02-11 13:34                   ` Richard Stallman
@ 2008-02-11 23:48                     ` Leo
  0 siblings, 0 replies; 37+ messages in thread
From: Leo @ 2008-02-11 23:48 UTC (permalink / raw)
  To: rms; +Cc: emacs-pretest-bug, hanche

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/




^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2008-02-11 23:48 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-05 16:55 23.0.60; Emacs should survive a lost X connection Harald Hanche-Olsen
2008-02-10 21:02 ` Harald Hanche-Olsen
  -- strict thread matches above, loose matches on Subject: below --
2008-02-05 14:58 Harald Hanche-Olsen
2008-02-05 19:57 ` Dan Nicolaescu
2008-02-05 20:39   ` Harald Hanche-Olsen
2008-02-05 23:49   ` Dan Nicolaescu
2008-02-06 19:20     ` Richard Stallman
2008-02-06 20:07       ` Dan Nicolaescu
2008-02-08  4:16         ` Richard Stallman
2008-02-08  7:26           ` Dan Nicolaescu
2008-02-09  4:52             ` Richard Stallman
2008-02-09  5:04               ` Dan Nicolaescu
2008-02-10  3:10                 ` Stefan Monnier
2008-02-10  8:03                   ` Dan Nicolaescu
2008-02-10 20:26                     ` Stefan Monnier
2008-02-11 13:35                       ` Richard Stallman
2008-02-10 22:08                     ` Stefan Monnier
2008-02-11  5:34                       ` Dan Nicolaescu
2008-02-11 14:41                         ` Stefan Monnier
2008-02-11 17:16                           ` Dan Nicolaescu
2008-02-10  3:20                 ` Richard Stallman
2008-02-10  8:03                   ` Dan Nicolaescu
2008-02-10 15:36                     ` Stefan Monnier
2008-02-10  8:27           ` Harald Hanche-Olsen
2008-02-10  8:58             ` Miles Bader
2008-02-10  9:34               ` Harald Hanche-Olsen
2008-02-10 13:19                 ` Miles Bader
2008-02-10 16:55                   ` Harald Hanche-Olsen
     [not found]           ` <20080208.195113.190255739.hanche@math.ntnu.no>
2008-02-10 19:04             ` Richard Stallman
2008-02-10 19:44               ` Harald Hanche-Olsen
2008-02-10 22:09                 ` Leo
2008-02-10 23:26                   ` Dan Nicolaescu
2008-02-10 23:38                     ` Leo
2008-02-11 13:34                   ` Richard Stallman
2008-02-11 23:48                     ` Leo
2008-02-11  0:17             ` Richard Stallman
2008-02-11 13:39               ` Harald Hanche-Olsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.