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: Re: allocate_string_data memory corruption Date: Wed, 18 Jan 2006 18:56:34 -0500 Message-ID: <87wtgxdr9p.fsf@stupidchicken.com> References: <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 1137633272 22096 80.91.229.2 (19 Jan 2006 01:14:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 19 Jan 2006 01:14:32 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 19 02:14:31 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 1EzONc-0003vi-Mw for ged-emacs-devel@m.gmane.org; Thu, 19 Jan 2006 02:14:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzOQ2-0005DG-4U for ged-emacs-devel@m.gmane.org; Wed, 18 Jan 2006 20:16:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EzNBr-0001oq-MA for emacs-devel@gnu.org; Wed, 18 Jan 2006 18:58:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EzNBp-0001mB-Uw for emacs-devel@gnu.org; Wed, 18 Jan 2006 18:58:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzNBo-0001kN-Ur for emacs-devel@gnu.org; Wed, 18 Jan 2006 18:58:09 -0500 Original-Received: from [18.19.6.82] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EzNFl-0007Wi-AC for emacs-devel@gnu.org; Wed, 18 Jan 2006 19:02:13 -0500 Original-Received: by localhost.localdomain (Postfix, from userid 1000) id 91C0F1208EA; Wed, 18 Jan 2006 18:56:34 -0500 (EST) Original-To: Ken Raeburn In-Reply-To: (Ken Raeburn's message of "Wed, 18 Jan 2006 16:35:52 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:49247 Archived-At: Ken Raeburn writes: > By "no-op", do you mean, for example, a macro or previously-defined > empty function, such that the compiler will produce different code > for allocate_string_data? Sorry, that was the wrong phrase to use. I meant that check_sblock only scans the values in current_sblock, and aborts if they are illegal -- it does not write into the heap at any point. > Is this consistent across OSes? E.g., Linux and *BSD or Solaris? > How about compiler versions? Could be a subtle OS bug in task > switching or something. Anything interesting going on with signal > handlers at the time? The user is running SuSE 9.1. He has a certain Emacs Lisp setup that he can use to crash Emacs reproducibly, when hyperthreading is turned on. Without hyperthreading, he has gotten one or two strange bus errors, but these seem to be difficult to reproduce, and we're not sure if they are real. His Emacs Lisp setup seems to be pretty idiosyncratic. He said before that he didn't know how to whittle it down into a small test case, but I can ask him again.