From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: erroneous auto-save-list file Date: Thu, 15 Nov 2007 09:51:04 +0100 Message-ID: <87d4ub28p3.fsf@escher.local.home> References: <87mytopcqc.fsf@escher.local.home> <87tznvsu7i.fsf@escher.local.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1195116716 14305 80.91.229.12 (15 Nov 2007 08:51:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2007 08:51:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 15 09:52:01 2007 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 1IsaS6-00026f-0L for ged-emacs-devel@m.gmane.org; Thu, 15 Nov 2007 09:51:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IsaRt-0000xu-Be for ged-emacs-devel@m.gmane.org; Thu, 15 Nov 2007 03:51:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IsaRT-0000Lg-3c for emacs-devel@gnu.org; Thu, 15 Nov 2007 03:51:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IsaRS-0000K3-8A for emacs-devel@gnu.org; Thu, 15 Nov 2007 03:51:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IsaRR-0000JO-RY for emacs-devel@gnu.org; Thu, 15 Nov 2007 03:51:17 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IsaRR-0000sk-DR for emacs-devel@gnu.org; Thu, 15 Nov 2007 03:51:17 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IsaRN-00031G-PK for emacs-devel@gnu.org; Thu, 15 Nov 2007 08:51:13 +0000 Original-Received: from i577bc861.versanet.de ([87.123.200.97]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Nov 2007 08:51:13 +0000 Original-Received: from Stephen.Berman by i577bc861.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Nov 2007 08:51:13 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 49 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: i577bc861.versanet.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) 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:83252 Archived-At: On Fri, 09 Nov 2007 21:59:32 -0500 Richard Stallman wrote: > When > the initial abort occurred, resulting in the erroneous auto-save-list > file, Emacs was not running under gdb, but, as I wrote in my bug report > about the abort, even reproducing it under gdb yielded no backtrace, why > I don't know. > > That could be a serious problem in GDB. It would be good to talk > with GDB developers about how to investigate it. Since the bug's > cause is known, they could focus on figuring out why GDB fails > to give a backtrace. I've had a fruitful exchange about this on the gdb-devel list, and it turns out gdb does give a backtrace. I had been able to get it because I had already killed the emacs process, which was the only way to release my desktop after emacs aborted. Michael Snyder explained it like this: >> In a nutshell, your emacs process has a lock on a shared >> resource (the X keyboard-and-mouse "focus"). It is intended >> to keep that lock only briefly, but while in posession of the >> lock, it aborts. >> >> Normally an abort would result in the freeing of the lock, >> but since gdb stops the emacs process from exiting, the lock >> is not freed, resulting in a deadlock when some other process >> (eg. xterm) needs the lock. >> >> This is a problem, but a normal and predictable one. >> GDB cannot tell when a debugged process is in posession >> of a lock that will cause other processes to deadlock, >> and it has no way of freeing such locks. He suggested starting gdb in a virtual console and attaching the emacs process to this. After emacs aborted under X, I switched to the virtual console and was able to get a backtrace.[1] So there's no problem here with gdb and since Jan D. had already fixed the bug which caused Emacs to abort, this issue can be declared closed. Steve Berman Footnotes: [1] The backtrace was not very informative, containing lines like this: #5 0xb7c7b1c1 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #6 0x085c2d00 in ?? () This may be because the shared libraries installed on my system are stripped.