From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: allocate_string_data memory corruption Date: Wed, 18 Jan 2006 11:57:02 -0500 Message-ID: <87vewha2zl.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1137615100 19879 80.91.229.2 (18 Jan 2006 20:11:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 18 Jan 2006 20:11:40 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 18 21:11:39 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EzJeI-00061R-Nw for ged-emacs-devel@m.gmane.org; Wed, 18 Jan 2006 21:11:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzJgh-0005jl-IF for ged-emacs-devel@m.gmane.org; Wed, 18 Jan 2006 15:13:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EzGfv-0003Ec-2d for emacs-devel@gnu.org; Wed, 18 Jan 2006 12:00:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EzGdv-0002cl-2A for emacs-devel@gnu.org; Wed, 18 Jan 2006 11:58:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzGdr-0002bl-CH for emacs-devel@gnu.org; Wed, 18 Jan 2006 11:58:41 -0500 Original-Received: from [18.19.6.82] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EzGhk-00079n-H4 for emacs-devel@gnu.org; Wed, 18 Jan 2006 12:02:40 -0500 Original-Received: by localhost.localdomain (Postfix, from userid 1000) id 511091208EA; Wed, 18 Jan 2006 11:57:02 -0500 (EST) Original-To: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:49235 Archived-At: 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?