unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Stallman <rms@gnu.org>
To: Harald Hanche-Olsen <hanche@math.ntnu.no>
Cc: emacs-devel@gnu.org
Subject: Re: 23.0.60; Emacs should survive a lost X connection
Date: Sun, 10 Feb 2008 19:17:22 -0500	[thread overview]
Message-ID: <E1JOMMM-0001g1-Rc@fencepost.gnu.org> (raw)
In-Reply-To: <20080208.195113.190255739.hanche@math.ntnu.no> (message from Harald Hanche-Olsen on Fri, 08 Feb 2008 19:51:13 +0100 (CET))

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




  parent reply	other threads:[~2008-02-11  0:17 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
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 [this message]
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=E1JOMMM-0001g1-Rc@fencepost.gnu.org \
    --to=rms@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=hanche@math.ntnu.no \
    /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).