From: Dan Nicolaescu <dann@ics.uci.edu>
To: rms@gnu.org
Cc: emacs-pretest-bug@gnu.org, hanche@math.ntnu.no
Subject: Re: 23.0.60; Emacs should survive a lost X connection
Date: Wed, 06 Feb 2008 12:07:52 -0800 [thread overview]
Message-ID: <200802062007.m16K7r78005498@sallyv1.ics.uci.edu> (raw)
In-Reply-To: <E1JMppH-0008LZ-63@fencepost.gnu.org> (Richard Stallman's message of "Wed, 06 Feb 2008 14:20:55 -0500")
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).
next prev parent reply other threads:[~2008-02-06 20:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 14:58 23.0.60; Emacs should survive a lost X connection 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 [this message]
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-13 3:09 ` after-delete-terminal-functions (was: 23.0.60; Emacs should survive a lost X connection) Stefan Monnier
2008-02-13 22:00 ` Richard Stallman
2008-02-13 22:24 ` after-delete-terminal-functions Stefan Monnier
2008-02-18 17:31 ` after-delete-terminal-functions Richard Stallman
2008-03-29 3:44 ` after-delete-terminal-functions Stefan Monnier
2008-02-10 3:20 ` 23.0.60; Emacs should survive a lost X connection 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200802062007.m16K7r78005498@sallyv1.ics.uci.edu \
--to=dann@ics.uci.edu \
--cc=emacs-pretest-bug@gnu.org \
--cc=hanche@math.ntnu.no \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).