From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: 23.0.60; Emacs should survive a lost X connection Date: Sun, 10 Feb 2008 19:17:22 -0500 Message-ID: References: <200802062007.m16K7r78005498@sallyv1.ics.uci.edu> <20080208.195113.190255739.hanche@math.ntnu.no> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1202689109 17975 80.91.229.12 (11 Feb 2008 00:18:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2008 00:18:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Harald Hanche-Olsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 11 01:18:52 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JOMNm-0003aT-RB for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2008 01:18:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JOMNJ-0005Ld-B1 for ged-emacs-devel@m.gmane.org; Sun, 10 Feb 2008 19:18:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JOMMP-0004qD-KR for emacs-devel@gnu.org; Sun, 10 Feb 2008 19:17:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JOMMO-0004oW-3A for emacs-devel@gnu.org; Sun, 10 Feb 2008 19:17:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JOMMN-0004oQ-O6 for emacs-devel@gnu.org; Sun, 10 Feb 2008 19:17:23 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JOMMN-0007Z0-I7 for emacs-devel@gnu.org; Sun, 10 Feb 2008 19:17:23 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1JOMMM-0001g1-Rc; Sun, 10 Feb 2008 19:17:22 -0500 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)) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:88691 Archived-At: #7 0x00000000 in ?? () #8 0x88a6aa24 in sigaction () from /lib/libpthread.so.2 #9 0x08180e2f in internal_condition_case (bfun=0x812ceb4 , handlers=137829497, hfun=0x8126584 ) at eval.c:1469 #10 0x08120736 in command_loop_2 () at keyboard.c:1370 #11 0x08180b3d in internal_catch (tag=0, func=0x8120718 , 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;