emacs-devel
[Top][All Lists]
Advanced

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

Re: 23.0.60; Emacs should survive a lost X connection


From: Harald Hanche-Olsen
Subject: Re: 23.0.60; Emacs should survive a lost X connection
Date: Mon, 11 Feb 2008 14:39:52 +0100 (CET)

+ Richard Stallman <address@hidden>:

> 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




reply via email to

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