From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: allocate_string_data memory corruption Date: Thu, 19 Jan 2006 20:14:13 -0500 Message-ID: References: <87vewha2zl.fsf@stupidchicken.com> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1137719991 1005 80.91.229.2 (20 Jan 2006 01:19:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2006 01:19:51 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 20 02:19:49 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 1EzkwK-0002hF-0D for ged-emacs-devel@m.gmane.org; Fri, 20 Jan 2006 02:19:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ezkym-0002Vd-Cu for ged-emacs-devel@m.gmane.org; Thu, 19 Jan 2006 20:22:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EzkwY-0001QV-De for emacs-devel@gnu.org; Thu, 19 Jan 2006 20:19:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EzkwX-0001Pe-96 for emacs-devel@gnu.org; Thu, 19 Jan 2006 20:19:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzkwW-0001PK-8h for emacs-devel@gnu.org; Thu, 19 Jan 2006 20:19:56 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ezl0d-000841-Pv for emacs-devel@gnu.org; Thu, 19 Jan 2006 20:24:11 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Ezkqz-0008VZ-CM; Thu, 19 Jan 2006 20:14:13 -0500 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:49285 Archived-At: /* 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 (); ... My first question is, is the value of `data' itself the same at those two places? In other words, did the memory locations pointed to get clobbered, or did the variable `data' itself get clobbered? Another question: suppose you replace check_sblock with a delay loop. Does it still happen? Try various values of the delay. I just noticed that allocate_string does nothing to prevent signals from being handled. Neither does Fcons. The result is that if a signal comes inside these lines, /* Pop a Lisp_String off the free-list. */ s = string_free_list; string_free_list = NEXT_FREE_LISP_STRING (s); then the same string header object could be allocated both at main program level and in the signal handler. Or other things could go wrong, depending on precisely where the signal arrived. So it seems that these functions need BLOCK_INPUT.