From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: allocate_string_data memory corruption Date: Thu, 19 Jan 2006 00:06:25 +0200 Message-ID: References: <87vewha2zl.fsf@stupidchicken.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1137627623 4090 80.91.229.2 (18 Jan 2006 23:40:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 18 Jan 2006 23:40:23 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 19 00:40:20 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 1EzMuZ-0007bt-5n for ged-emacs-devel@m.gmane.org; Thu, 19 Jan 2006 00:40:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzMwx-0006ic-14 for ged-emacs-devel@m.gmane.org; Wed, 18 Jan 2006 18:42:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EzLiv-0004kD-OI for emacs-devel@gnu.org; Wed, 18 Jan 2006 17:24:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EzLit-0004j1-4i for emacs-devel@gnu.org; Wed, 18 Jan 2006 17:24:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzLis-0004ip-UV for emacs-devel@gnu.org; Wed, 18 Jan 2006 17:24:11 -0500 Original-Received: from [192.114.186.17] (helo=gandalf.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EzLmo-0005Ui-B8 for emacs-devel@gnu.org; Wed, 18 Jan 2006 17:28:14 -0500 Original-Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HPU00528; Thu, 19 Jan 2006 00:12:20 +0200 (IST) Original-Received: from HOME-C4E4A596F7 (IGLD-84-228-160-15.inter.net.il [84.228.160.15]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CMW10803 (AUTH halo1); Thu, 19 Jan 2006 00:06:22 +0200 (IST) Original-To: Chong Yidong In-reply-to: <87vewha2zl.fsf@stupidchicken.com> (message from Chong Yidong on Wed, 18 Jan 2006 11:57:02 -0500) 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:49244 Archived-At: > 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. Btw, does the value of `data' itself change in any way? You didn't show its value at the offending line. > There is clearly no assignment to any of the sdata structures in these > functions. > > Any ideas? One idea is to put watchpoints on the relevant memory addresses and see who hits them. For maximum reliability, look at the machine instruction whose address GDB shows when the watchpoint is hit, and then disassemble around that address to see what source line(s) did that.