From: Richard Stallman <rms@gnu.org>
Cc: mlm@timesten.com, bug-gnu-emacs@gnu.org
Subject: Re: core dump triggered by garbage collection (?)
Date: Sun, 07 Sep 2003 16:23:02 -0400 [thread overview]
Message-ID: <E19w63q-0003Dw-Vq@fencepost.gnu.org> (raw)
In-Reply-To: <16216.15392.176843.420150@oscar.mv.timesten.com> (message from Mark McAuliffe on Fri, 5 Sep 2003 00:32:48 -0700)
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.
prev parent reply other threads:[~2003-09-07 20:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-28 17:16 core dump triggered by garbage collection (?) Mark McAuliffe
2003-09-01 2:22 ` Richard Stallman
2003-09-05 7:32 ` Mark McAuliffe
2003-09-07 20:23 ` Richard Stallman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E19w63q-0003Dw-Vq@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=bug-gnu-emacs@gnu.org \
--cc=mlm@timesten.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).