unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* allocate_string_data memory corruption
@ 2006-01-18 16:57 Chong Yidong
  2006-01-18 20:48 ` Stefan Monnier
                   ` (3 more replies)
  0 siblings, 4 replies; 58+ messages in thread
From: Chong Yidong @ 2006-01-18 16:57 UTC (permalink / 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?

^ permalink raw reply	[flat|nested] 58+ messages in thread

end of thread, other threads:[~2006-01-30  1:06 UTC | newest]

Thread overview: 58+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-18 16:57 allocate_string_data memory corruption Chong Yidong
2006-01-18 20:48 ` 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

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).