emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

x_catch_error vs. internal_condition_case (Re: crash on ssh disconnect)


From: Károly Lőrentey
Subject: x_catch_error vs. internal_condition_case (Re: crash on ssh disconnect)
Date: Sat, 29 Jul 2006 20:43:46 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.52 (gnu/linux)

Cc:d to Emacs-devel.  While the exact abort path below is specific to
the multi-tty branch, I wonder if the trunk might not exhibit
something similar.  Emacs always seemed a bit flaky after unexpected X
connection problems.

Dan Nicolaescu <address@hidden> writes:
> I had an emacsclient X11 frame running over ssh. For some reason the
> ssh session got disconnected, but emacs also crashed when this
> happened. I had it running in gdb, so I could look at the
> backtrace. 

> #0  0x00157402 in __kernel_vsyscall ()
> #1  0x0019d456 in ?? ()
> #2  0x080edcab in abort () at 
> /home/dann/build/MTTY-emacs/emacs/src/emacs.c:465
> #3  0x08152ccd in internal_condition_case_2 (bfun=Could not find the frame 
> base for "internal_condition_case_2".)
>     at /home/dann/build/MTTY-emacs/emacs/src/eval.c:1548
> #4  0x080600bd in Fdelete_frame (frame=172503524, force=137599225)
>     at /home/dann/build/MTTY-emacs/emacs/src/frame.c:1423
> #5  0x080caa61 in x_connection_closed (dpy=0x9dd2648, error_message=Variable 
> "error_message" is not available.)
>     at /home/dann/build/MTTY-emacs/emacs/src/xterm.c:7721
> #6  0x080cabeb in x_io_error_quitter (display=0x9dd2648)
>     at /home/dann/build/MTTY-emacs/emacs/src/xterm.c:7859

This is due to a recent overhaul of the x_catch_errors API.
Apparently, it is now invalid to safely call Lisp code while an
x_catch_error is in effect.  This is because Fsignal (err,
unwind_to_catch) calls x_fully_uncatch_errors.

In order to prevent X disconnects from bringing Emacs down, the
delete-frame call above must succeed regardless of any errors while it
executes `delete-frame-functions'.  Removing the x_error_catch around
the hook invocation does not seem viable, as that may enter
x_connection_closed recursively.

I looked at all the x_error_catch invocations, and since Chong
Yidong's February fixes, they seem to be either trivial wrappers
around an X library call, or they are careful to install an unwind to
exit x_error_catch.  I think it is therefore unnecessary to call
x_fully_uncatch_errors, so in the multi-tty branch (patch-576) I
disabled Richard's 2006-03-11 change.

-- 
Károly

Attachment: pgpP9ftarR5vf.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]