From espenhw@grumblesmurf.org Wed Nov 5 14:45:28 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.0 required=4.0 tests=BAYES_00,IMPRONONCABLE_2, RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 5 Nov 2008 22:45:28 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mA5MjO3F031439 for ; Wed, 5 Nov 2008 14:45:25 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kxr7s-0001g7-5V for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2008 17:45:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kxr7r-0001fq-C4 for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2008 17:45:23 -0500 Received: from [199.232.76.173] (port=55021 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kxr7r-0001fm-3C for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2008 17:45:23 -0500 Received: from friends.chrissearle.org ([78.47.168.123]:45233 helo=bryanek.chrissearle.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kxr7q-0000Vf-BJ for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2008 17:45:22 -0500 Received: from cm-84.209.20.118.getinternet.no ([84.209.20.118] helo=localhost) by bryanek.chrissearle.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Kxr7o-0005gA-OJ for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2008 23:45:21 +0100 Received: from localhost ([127.0.0.1] helo=demokritos.grumblesmurf.org) by localhost with esmtp (Exim 4.69) (envelope-from ) id 1Kxr7n-00060O-Gr for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2008 23:45:19 +0100 From: Espen Wiborg To: bug-gnu-emacs@gnu.org Date: Wed, 05 Nov 2008 23:39:37 +0100 Message-ID: <87vdv1sspi.fsf@demokritos.grumblesmurf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SA-Exim-Connect-IP: 84.209.20.118 X-SA-Exim-Mail-From: espenhw@grumblesmurf.org Subject: 23.0.60; Emacs daemon behaves strangely if client loses X connection X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on bryanek.chrissearle.org) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 1. Start emacs with "emacs -Q -daemon" 2. Create an X frame (emacsclient -c) 3. Kill your X server (or make your window manager crash, which is how I initially tickled this) 4. Restart X and try to create an X frame again. This time the frame is blank and doesn't respond to anything; the only way to get rid of the frame is by killing the daemon process. Attaching gdb to the daemon process when the frame creation hangs gives the stacktrace below. It appears to be hanging on the yes-or-no-p at the top of server-start, called because cmd_error_internal calls Fkill_emacs at keyboard.c:1274. #0 0xb80c6430 in __kernel_vsyscall () #1 0xb752dbcd in select () from /lib/tls/i686/cmov/libc.so.6 #2 0x081cdbea in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137944345, wait_proc=0x0, just_wait_proc=0) at process.c:4450 #3 0x08130498 in read_char (commandflag=1, nmaps=2, maps=0xbfdc7780, prev_event=137944345, used_mouse_menu=0xbfdc7830, end_time=0x0) at keyboard.c:4038 #4 0x081323b2 in read_key_sequence (keybuf=0xbfdc78e4, bufsize=30, prompt=137944345, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9344 #5 0x08134013 in command_loop_1 () at keyboard.c:1621 #6 0x08190410 in internal_condition_case ( bfun=0x8133e30 , handlers=137987553, hfun=0x812d940 ) at eval.c:1511 #7 0x0812cea5 in command_loop_2 () at keyboard.c:1338 #8 0x081904ea in internal_catch (tag=138082801, func=0x812ce80 , arg=137944345) at eval.c:1247 #9 0x0812d747 in command_loop () at keyboard.c:1303 #10 0x0812db3b in recursive_edit_1 () at keyboard.c:942 #11 0x08150545 in read_minibuf (map=137937349, initial=137944345, prompt=, backup_n=, expflag=0, histvar=138087945, histpos=0, defalt=137944345, #12 0x0819dba6 in Fyes_or_no_p (prompt=141802059) at fns.c:2792 #13 0x08191134 in Ffuncall (nargs=2, args=0xbfdc7cb0) at eval.c:3044 #14 0x081c6398 in Fbyte_code (bytestr=143351939, vector=147504412, maxdepth=) at bytecode.c:678 #15 0x08192f53 in funcall_lambda (fun=145209676, nargs=1, arg_vector=0xbfdc7e34) at eval.c:3231 #16 0x08190e13 in Ffuncall (nargs=2, args=0xbfdc7e30) at eval.c:3101 #17 0x081c6398 in Fbyte_code (bytestr=143296619, vector=145272100, maxdepth=) at bytecode.c:678 #18 0x08192f53 in funcall_lambda (fun=144357524, nargs=1, arg_vector=0xbfdc7f64) at eval.c:3231 #19 0x08190e13 in Ffuncall (nargs=2, args=0xbfdc7f60) at eval.c:3101 #20 0x081c6398 in Fbyte_code (bytestr=143355483, vector=145176892, maxdepth=) at bytecode.c:678 #21 0x08192f53 in funcall_lambda (fun=145193476, nargs=0, arg_vector=0xbfdc80cc) at eval.c:3231 #22 0x08190e13 in Ffuncall (nargs=1, args=0xbfdc80c8) at eval.c:3101 #23 0x081921b1 in run_hook_with_args (nargs=1, args=0xbfdc80c8, cond=to_completion) at eval.c:2703 #24 0x08192372 in Frun_hooks (nargs=1, args=0xbfdc8164) at eval.c:2566 #25 0x08190fbe in Ffuncall (nargs=2, args=0xbfdc8160) at eval.c:3025 #26 0x08192039 in call1 (fn=138083185, arg1=138132537) at eval.c:2829 #27 0x081227b5 in Fkill_emacs (arg=-8) at emacs.c:2076 #28 0x0812d925 in cmd_error_internal (data=143401285, context=0xbfdc81c6 "") at keyboard.c:1274 #29 0x0812da27 in cmd_error (data=143401285) at keyboard.c:1222 #30 0x0819043c in internal_condition_case ( bfun=0x8133e30 , handlers=137987553, hfun=0x812d940 ) at eval.c:1501 #31 0x0812cea5 in command_loop_2 () at keyboard.c:1338 #32 0x081904ea in internal_catch (tag=137983529, func=0x812ce80 , arg=137944345) at eval.c:1247 #33 0x0812d79f in command_loop () at keyboard.c:1317 #34 0x0812db3b in recursive_edit_1 () at keyboard.c:942 #35 0x0812dc84 in Frecursive_edit () at keyboard.c:1004 #36 0x081239df in main (argc=3, argv=0xbfdc8804) at emacs.c:1777 Lisp Backtrace: "yes-or-no-p" (0xbfdc7cb4) "server-start" (0xbfdc7e34) "server-mode" (0xbfdc7f64) 0x8a77a04 PVEC_COMPILED "run-hooks" (0xbfdc8164) From dann@mothra.ics.uci.edu Thu Nov 6 21:08:25 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-8.9 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1310) by emacsbugs.donarmstrong.com; 7 Nov 2008 05:08:25 +0000 Received: from sallyv2.ics.uci.edu (sallyv2.ics.uci.edu [128.195.1.120]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mA758Mtt031797 for <1310@emacsbugs.donarmstrong.com>; Thu, 6 Nov 2008 21:08:23 -0800 Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by sallyv2.ics.uci.edu (8.13.7+Sun/8.13.7) with ESMTP id mA7587OF010312; Thu, 6 Nov 2008 21:08:11 -0800 (PST) Received: (from dann@localhost) by mothra.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id mA75866Z012800; Thu, 6 Nov 2008 21:08:06 -0800 (PST) Date: Thu, 6 Nov 2008 21:08:06 -0800 (PST) Message-Id: <200811070508.mA75866Z012800@mothra.ics.uci.edu> From: Dan Nicolaescu To: Espen Wiborg Cc: 1310@debbugs.gnu.org Subject: Re: bug#1310: 23.0.60; Emacs daemon behaves strangely if client loses X connection References: <87vdv1sspi.fsf@demokritos.grumblesmurf.org> X-Debbugs-No-Ack: yes In-Reply-To: <87vdv1sspi.fsf@demokritos.grumblesmurf.org> (Espen Wiborg's message of "Wed, 05 Nov 2008 23:39:37 +0100") Lines: 38 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-ICS-MailScanner-Information: Please contact the ISP for more information X-ICS-MailScanner-ID: mA7587OF010312 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu Espen Wiborg writes: > 1. Start emacs with "emacs -Q -daemon" > > 2. Create an X frame (emacsclient -c) > > 3. Kill your X server (or make your window manager crash, which is how I > initially tickled this) > > 4. Restart X and try to create an X frame again. This time the frame is > blank and doesn't respond to anything; the only way to get rid of the > frame is by killing the daemon process. > > Attaching gdb to the daemon process when the frame creation hangs gives > the stacktrace below. > > It appears to be hanging on the yes-or-no-p at the top of server-start, > called because cmd_error_internal calls Fkill_emacs at keyboard.c:1274. Thanks for the detailed report! Can you please try this patch? I am not entirely convinced it's completely right, I can't kill my X server at the moment, and I could not reproduce the problem with Xnest. --- keyboard.c.~1.978.~ 2008-11-02 21:49:25.000000000 -0800 +++ keyboard.c 2008-11-06 21:04:55.000000000 -0800 @@ -1265,7 +1265,7 @@ cmd_error_internal (data, context) /* If the window system or terminal frame hasn't been initialized yet, or we're not interactive, write the message to stderr and exit. */ else if (!sf->glyphs_initialized_p - || FRAME_INITIAL_P (sf) + || (FRAME_INITIAL_P (sf) && !IS_DAEMON) || noninteractive) { print_error_message (data, Qexternal_debugging_output, From espenhw@grumblesmurf.org Mon Nov 10 11:48:39 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1310) by emacsbugs.donarmstrong.com; 10 Nov 2008 19:48:39 +0000 Received: from bryanek.chrissearle.org (friends.chrissearle.org [78.47.168.123]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mAAJmZxm009241 for <1310@emacsbugs.donarmstrong.com>; Mon, 10 Nov 2008 11:48:37 -0800 Received: from [127.0.0.1] (helo=www.chrissearle.org) by bryanek.chrissearle.org with esmtp (Exim 4.63) (envelope-from ) id 1KzckT-00051D-RC; Mon, 10 Nov 2008 20:48:33 +0100 Received: from 84.209.20.118 (SquirrelMail authenticated user espenhw) by www.chrissearle.org with HTTP; Mon, 10 Nov 2008 20:48:33 +0100 (CET) Message-ID: <51066.84.209.20.118.1226346513.squirrel@www.chrissearle.org> Date: Mon, 10 Nov 2008 20:48:33 +0100 (CET) Subject: Re: bug#1310: 23.0.60; Emacs daemon behaves strangely if client loses X connection From: "Espen Wiborg" To: "Dan Nicolaescu" Cc: 1310@debbugs.gnu.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: espenhw@grumblesmurf.org X-SA-Exim-Scanned: No (on bryanek.chrissearle.org); SAEximRunCond expanded to false On Mon, November 10, 2008 09:29, Dan Nicolaescu wrote: > "Espen Wiborg" writes: > > With the patch the behavior is less deterministic: > > > > Emacs usually survives the first X crash, and will at this point happily serve > > clients and create frames. > > > > The second crash usually calls abort() with the following backtrace: > > Unfortunately, I am still not able to play with killing X, so I can only > offer guesses, but no real debugging... I test by starting the daemon under a different name (./emacs -Q --daemon=testing) and then run a secondary X server serving just the client with startx `which emacsclient` -c -s /tmp/emacs`id -u`/testing -- :1 I can then zap the secondary X, e.g. with C-M-Backspace, without affecting my real session. This trick is also useful to test strange resolutions, color depths etc. > Does the problem happen if you configure emacs without Gtk (i.e. > --with-x-toolkit=lucid)? No, it doesn't. Or at least it happens much less frequently; in 35-40 tries I could only provoke something once, but that seems to have been a clean shutdown (which is infinitely preferable to the hang I get with Gtk enabled). > Also, can you try if the problem happens if you do: > in a text console: emacs -Q -f server-start > now start X, and run emacsclient -c to connect to the server > and kill X > (this is to verify if the problem is related to --daemon, I am guessing > it should not be, and similar problems were fixed long time ago...) Interesting. With the Gtk-enabled Emacs, I get the same behavior as with --daemon, but when I try to open a new frame after killing X, my console is spammed with (emacs:6078): GLib-WARNING **: g_main_context_prepare() called recursively from within a source's check() or prepare() member. ad infinitum. So it definitely looks as if Gtk is the culprit (or at least part of the problem). I'm running this on Ubuntu 8.10, Intrepid Ibex; I appeare to have Gtk 2.14.4-0ubuntu1 installed. -- Espen Wiborg - Veritas vos liberabit A twisted mind is a joy forever. From monnier@iro.umontreal.ca Sat Dec 20 20:15:47 2008 Received: (at 1310) by emacsbugs.donarmstrong.com; 21 Dec 2008 04:15:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: ** X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=2.5 required=4.0 tests=MURPHY_DRUGS_REL8,XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mBL4Fidm021448 for <1310@emacsbugs.donarmstrong.com>; Sat, 20 Dec 2008 20:15:45 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAAtSTUlMCqBi/2dsb2JhbACBbLpsWJAFhkOBWg X-IronPort-AV: E=Sophos;i="4.36,257,1228107600"; d="scan'208";a="31330203" Received: from 76-10-160-98.dsl.teksavvy.com (HELO pastel.home) ([76.10.160.98]) by ironport2-out.teksavvy.com with ESMTP; 20 Dec 2008 23:15:38 -0500 Received: by pastel.home (Postfix, from userid 20848) id 3937884A4; Sat, 20 Dec 2008 23:15:38 -0500 (EST) From: Stefan Monnier To: Ulrich Mueller Cc: 1310@debbugs.gnu.org Subject: Re: Emacs daemon dies at Xorg crash Message-ID: References: <1229454957.21129.0.camel@localhost> <18760.56870.137654.853165@a1ihome1.kph.uni-mainz.de> <87k59yssad.fsf@cyd.mit.edu> <200812171708.mBHH8hPO008789@mothra.ics.uci.edu> <18761.21020.890676.865384@a1ihome1.kph.uni-mainz.de> <200812172251.mBHMp3ce010724@mothra.ics.uci.edu> <18762.15396.428952.119630@a1i15.kph.uni-mainz.de> <200812181914.mBIJE7qb013842@mothra.ics.uci.edu> <18762.51405.911216.76307@a1ihome1.kph.uni-mainz.de> <200812182249.mBIMnYK6014142@mothra.ics.uci.edu> <18765.15064.497113.969975@a1ihome1.kph.uni-mainz.de> Date: Sat, 20 Dec 2008 23:15:38 -0500 In-Reply-To: <18765.15064.497113.969975@a1ihome1.kph.uni-mainz.de> (Ulrich Mueller's message of "Sat, 20 Dec 2008 19:35:04 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > So, any reason why above patch cannot be checked in? I've installed a slightly more bold patch which just removes the FRAME_INITIAL_P check altogether. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 17 13:44:27 2009 Received: (at control) by debbugs.gnu.org; 17 Dec 2009 18:44:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLLKt-00005n-18 for submit@debbugs.gnu.org; Thu, 17 Dec 2009 13:44:27 -0500 Received: from pantheon-po29.its.yale.edu ([130.132.50.124]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NLLFt-0008V6-6u for control@debbugs.gnu.org; Thu, 17 Dec 2009 13:39:17 -0500 Received: from furry (dhcp128036014246.central.yale.edu [128.36.14.246]) (authenticated bits=0) by pantheon-po29.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id nBHIdCkj019317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 17 Dec 2009 13:39:12 -0500 Received: by furry (Postfix, from userid 1000) id A8C5CC05D; Thu, 17 Dec 2009 13:39:12 -0500 (EST) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 1310 Date: Thu, 17 Dec 2009 13:39:12 -0500 Message-ID: <87bphxwilr.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Debbugs-Envelope-To: control X-Mailman-Approved-At: Thu, 17 Dec 2009 13:44:26 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org close 1310 thanks From unknown Wed Jun 18 23:08:46 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 15 Jan 2010 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator