From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: allocate_string_data memory corruption Date: Thu, 19 Jan 2006 00:48:12 +0100 Message-ID: <85oe29gksj.fsf@lola.goethe.zz> 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 1137656219 21681 80.91.229.2 (19 Jan 2006 07:36:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 19 Jan 2006 07:36:59 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 19 08:36:54 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 1EzULl-0006Iu-Ck for ged-emacs-devel@m.gmane.org; Thu, 19 Jan 2006 08:36:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzUOB-0008KK-Bt for ged-emacs-devel@m.gmane.org; Thu, 19 Jan 2006 02:39:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EzUIF-0007SR-Mh for emacs-devel@gnu.org; Thu, 19 Jan 2006 02:33:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EzUID-0007S4-TL for emacs-devel@gnu.org; Thu, 19 Jan 2006 02:33:14 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzUIC-0007Rs-LW for emacs-devel@gnu.org; Thu, 19 Jan 2006 02:33:12 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EzUMC-0001vt-Ev for emacs-devel@gnu.org; Thu, 19 Jan 2006 02:37:20 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1EzUCk-0008D4-GG; Thu, 19 Jan 2006 02:27:35 -0500 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 5575B1C4F93F; Thu, 19 Jan 2006 00:48:13 +0100 (CET) Original-To: Eli Zaretskii In-Reply-To: (Eli Zaretskii's message of "Thu, 19 Jan 2006 00:06:25 +0200") 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:49259 Archived-At: Eli Zaretskii writes: >> From: Chong Yidong >> Date: Wed, 18 Jan 2006 11:57:02 -0500 >> >> /* 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 > > Are you in fact 110% sure the abort happens on the second debugging > check? Can you tell how did you verify this? (The line number shown > by GDB is not a reliable evidence.) > > Was this code compiled without optimizations? If not, recompile with > "-O0" and see if you get abort or crash in another place. In particular (from DEBUG): ** When you are trying to analyze failed assertions, it will be essential to compile Emacs either completely without optimizations or at least (when using GCC) with the -fno-crossjumping option. Failure to do so may make the compiler recycle the same abort call for all assertions in a given function, rendering the stack backtrace useless for identifying the specific failed assertion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum