From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: crash in GC Date: Fri, 24 May 2002 14:07:07 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200205240044.g4O0i9E01298@aztec.santafe.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1022263725 7067 127.0.0.1 (24 May 2002 18:08:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 24 May 2002 18:08:45 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17BJUb-0001ps-00 for ; Fri, 24 May 2002 20:08:45 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17BJkb-0000HE-00 for ; Fri, 24 May 2002 20:25:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17BJV4-0002uu-00; Fri, 24 May 2002 14:09:14 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 3.34 #1 (Debian)) id 17BJT1-0002qA-00; Fri, 24 May 2002 14:07:07 -0400 Original-To: sds@gnu.org In-Reply-To: (message from Sam Steingold on 24 May 2002 10:19:28 -0400) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4342 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4342 > From: Sam Steingold > Date: 24 May 2002 10:19:28 -0400 > > > Could you investigate a little further and try to find the data that > > is invalid or inconsistent? > > I am afraid not. All I have is the backtrace. > (I restarted Emacs in the same gdb since I need it for other work.) That is very unfortunate: it means that this bug report cannot be pursued at all. Please in the future try to leave the crashed session running as long as the thread that discusses the crash is alive. If you can afford that resourcewise, that is. Crashes inside GC generally mean that some memory corruption happened earlier, but the backtrace doesn't say where and when. It is impossible to debug such problems armed with the backtrace alone; you need to examine the relevant C and Lisp data structures, and you need to check several hypotheses about the possible cause(s) of the corruption. You can't even start thinking about these issues without knowing the extent of data structures that are corrupted, and without access to the array that records the GC history.