From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.bugs Subject: Re: core dump triggered by garbage collection (?) Date: Sun, 07 Sep 2003 16:23:02 -0400 Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <200308281716.h7SHGK012200@mis-dns.mv.timesten.com> <16216.15392.176843.420150@oscar.mv.timesten.com> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1062967028 10575 80.91.224.253 (7 Sep 2003 20:37:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 7 Sep 2003 20:37:08 +0000 (UTC) Cc: mlm@timesten.com, bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 07 22:37:06 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19w6HR-0005DV-00 for ; Sun, 07 Sep 2003 22:37:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 19w69n-00077H-PW for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Sep 2003 16:29:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 19w68x-0006hB-HL for bug-gnu-emacs@gnu.org; Sun, 07 Sep 2003 16:28:19 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 19w68q-0006ZD-Hn for bug-gnu-emacs@gnu.org; Sun, 07 Sep 2003 16:28:15 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 19w68l-0006YJ-6P for bug-gnu-emacs@gnu.org; Sun, 07 Sep 2003 16:28:07 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.20) id 19w63q-0003Dw-Vq; Sun, 07 Sep 2003 16:23:02 -0400 Original-To: Mark McAuliffe In-reply-to: <16216.15392.176843.420150@oscar.mv.timesten.com> (message from Mark McAuliffe on Fri, 5 Sep 2003 00:32:48 -0700) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:5755 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:5755 In all three cases, the strings that appear before the corruption are numbers. Since the crash always seems to happen when I try to read mail with VM, I assume those numbers are the message numbers in the VM summary buffer. Significant? Helpful?? I dunno... It won't be easy to figure out the bug from this clue, but it is worth a try. Maybe the string that VM makes just after it makes the number is getting clobbered somehow. Can you take a look at a live process running VM when it has not crashed, and see what's in the string right after the message number? Also take a look at the code of VM to see what code makes that string, and what that string is used for. 0xa055a04: 0x00000000 0x0043c143 0x49f28038 0x00000006 0xa055a14: 0x40000000 0x00000032 0x0043c144 0x49f28038 0xa055a24: 0x00000006 0x40000000 0x00000032 0x0043c145 0xa055a34: 0x49f28038 0x00000006 0x40000000 0x0000002e 0xa055a44: 0x0043c146 0x49f28038 0x00000006 0x40000000 0xa055a54: 0x0000002e 0x00000000 0x00000000 0x00000006 0xa055a64: 0x40000000 0x00000020 0x00005480 0x489f3ce0 Is 0x43c143 the address of something? If so, what? In the middle of all this is the string "which is sent to the s", which probably isn't helpful for debugging, but it does sound kind of like an important clue from some bad mystery novel. If it is part of what was written erroneously into the block, it may teach us something, especially if you can find the place that it came from. If it is data in a string block, then it could be just some string text that was not clobbered. In that case it may not be relevant. Anyway... a lot of data here. I don't know if any of it is at all helpful. Please advise on where I might go from here. One question: I see in alloc.c that there is code ifdefed with GC_CHECK_STRING_BYTES. Presumably defining this symbol enables additional checks during garbage collection (how *did* I figure that out?? :-). Would it be helpful for me to compile a version with this flag set, given that the crash does happen with some regularity? I don't know, but I think it is worth a try.