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: Richard Stallman
Subject: Re: 23.0.60; Emacs should survive a lost X connection
Date: Sun, 10 Feb 2008 19:17:22 -0500

    #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 address@hidden on 8 feb 2008.  */
    x_fully_uncatch_errors ();
  #endif
  
    byte_stack_list = catch->byte_stack;
    gcprolist = catch->gcpro;




reply via email to

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