From: Chong Yidong <cyd@stupidchicken.com>
Subject: allocate_string_data memory corruption
Date: Wed, 18 Jan 2006 11:57:02 -0500 [thread overview]
Message-ID: <87vewha2zl.fsf@stupidchicken.com> (raw)
There's been some progress tracking down the hyperthreading /
allocate_string related crash. We can now reproduce a crash reliably.
However, the memory corruption seems to happen after a debugging call
which ought to be a no-op. I'd appreciate if someone could look
through this and give a suggestion.
The memory corruption occurs in the `data' variable, an sdata struct
in alloc.c:allocate_string_data(), shown below. (The following code
is not the same as in CVS; we've changed some things for debugging):
void
allocate_string_data (s, nchars, nbytes)
struct Lisp_String *s;
int nchars, nbytes;
{
struct sdata *data;
struct sblock *b;
...
data = b->next_free;
data->string = s;
s->data = SDATA_DATA (data);
data->nbytes = nbytes;
s->size = nchars;
s->size_byte = nbytes;
s->data[nbytes] = '\0';
bcopy (string_overrun_cookie, (char *) data + needed,
GC_STRING_OVERRUN_COOKIE_SIZE);
/* no crash here */
if (data->string != s || data->nbytes != nbytes) abort ();
check_sblock (current_sblock);
/* crash occured here */
if (data->string != s || data->nbytes != nbytes) abort ();
...
}
In this function, data->string is set to s, and nbytes is set to
nbytes. If check_sblock is a no-op, there should be no change.
However, we get an abort on the second debugging check:
#0 abort () at emacs.c:461
#1 0x0817499e in allocate_string_data (s=0x8d18778, nchars=8,
nbytes=8) at alloc.c:2013
s == (struct Lisp_String *) 0x8d18778
data->string == (struct Lisp_String *) 0x8d18788 <-- off by 16
nbytes == 8
data->nbytes == 200 <-- off by 192
nchars == 8
needed == 20
#2 0x08175311 in make_uninit_multibyte_string (nchars=8, nbytes=8)
at alloc.c:2472
The definition of check_sblock() we used is as follows:
void
check_sblock (b)
struct sblock *b;
{
struct sdata *from, *end, *from_end;
end = b->next_free;
for (from = &b->first_data; from < end; from = from_end)
{
int nbytes = from->nbytes;
if (from->string && (nbytes != string_bytes (from->string)))
abort ();
nbytes = SDATA_SIZE (nbytes);
from_end = (struct sdata *) ((char *) from + nbytes + GC_STRING_EXTRA);
}
if (from != end)
abort();
}
int
string_bytes (s)
struct Lisp_String *s;
{
int nbytes = (s->size_byte < 0 ? s->size & ~ARRAY_MARK_FLAG : s->size_byte);
if (!PURE_POINTER_P (s)
&& s->data
&& nbytes != SDATA_NBYTES (SDATA_OF_STRING (s)))
abort ();
return nbytes;
}
There is clearly no assignment to any of the sdata structures in these
functions.
Any ideas?
next reply other threads:[~2006-01-18 16:57 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-18 16:57 Chong Yidong [this message]
2006-01-18 20:48 ` allocate_string_data memory corruption Stefan Monnier
2006-01-20 0:45 ` Chong Yidong
2006-01-20 1:14 ` Richard M. Stallman
2006-01-20 3:48 ` Stefan Monnier
2006-01-23 20:21 ` Stefan Monnier
2006-01-24 17:23 ` Chong Yidong
2006-01-18 21:35 ` Ken Raeburn
2006-01-18 23:56 ` Chong Yidong
2006-01-19 8:53 ` Romain Francoise
2006-01-19 20:57 ` Stefan Monnier
2006-01-19 22:48 ` Kim F. Storm
2006-01-20 3:46 ` Stefan Monnier
2006-01-20 22:58 ` Richard M. Stallman
2006-01-25 3:26 ` Chong Yidong
2006-01-25 15:45 ` Richard M. Stallman
2006-01-20 1:14 ` Richard M. Stallman
2006-01-20 9:28 ` Ken Raeburn
2006-01-20 22:58 ` Richard M. Stallman
2006-01-18 22:06 ` Eli Zaretskii
2006-01-18 23:48 ` David Kastrup
2006-01-18 23:48 ` Chong Yidong
2006-01-19 1:15 ` Stefan Monnier
2006-01-19 3:21 ` Ken Raeburn
2006-01-19 4:36 ` Eli Zaretskii
2006-01-20 1:14 ` Richard M. Stallman
2006-01-20 3:56 ` Stefan Monnier
2006-01-20 14:49 ` Chong Yidong
2006-01-21 19:57 ` Richard M. Stallman
2006-01-22 17:37 ` Stefan Monnier
2006-01-20 22:58 ` Richard M. Stallman
2006-01-21 4:48 ` Stefan Monnier
2006-01-21 17:31 ` Chong Yidong
2006-01-22 3:57 ` Richard M. Stallman
2006-01-22 16:45 ` Stefan Monnier
2006-01-22 20:06 ` Andreas Schwab
2006-01-23 0:10 ` Richard M. Stallman
2006-01-23 0:35 ` Ken Raeburn
2006-01-23 1:58 ` Stefan Monnier
2006-01-23 2:06 ` Stefan Monnier
2006-01-24 16:46 ` Richard M. Stallman
2006-01-23 0:55 ` Stefan Monnier
2006-01-24 16:46 ` Richard M. Stallman
2006-01-24 17:57 ` Kim F. Storm
2006-01-24 18:33 ` Chong Yidong
2006-01-25 15:45 ` Richard M. Stallman
2006-01-26 1:41 ` Chong Yidong
2006-01-26 17:46 ` Richard M. Stallman
2006-01-26 18:40 ` Stefan Monnier
2006-01-26 19:45 ` Chong Yidong
2006-01-27 22:32 ` Richard M. Stallman
2006-01-27 23:33 ` Stefan Monnier
2006-01-29 14:53 ` Chong Yidong
2006-01-29 4:58 ` Chong Yidong
2006-01-30 0:57 ` Richard M. Stallman
2006-01-30 1:06 ` Chong Yidong
2006-01-27 22:32 ` Richard M. Stallman
2006-01-26 19:10 ` Chong Yidong
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=87vewha2zl.fsf@stupidchicken.com \
--to=cyd@stupidchicken.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).