From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Fix to long-standing crashes in GC Date: Thu, 20 May 2004 03:08:48 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <40A3BC23.8060000@math.ku.dk> <200405180013.i4I0Ddl15818@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1085037423 15383 80.91.224.253 (20 May 2004 07:17:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 May 2004 07:17:03 +0000 (UTC) Cc: teirllm@dms.auburn.edu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 20 09:16:57 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQhnV-0003jd-00 for ; Thu, 20 May 2004 09:16:57 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQhnV-0006AY-00 for ; Thu, 20 May 2004 09:16:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQhhG-0006lM-N1 for emacs-devel@quimby.gnus.org; Thu, 20 May 2004 03:10:30 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQhgd-0006QS-02 for emacs-devel@gnu.org; Thu, 20 May 2004 03:09:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQhfn-0005pV-Id for emacs-devel@gnu.org; Thu, 20 May 2004 03:09:32 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQhfj-0005kK-LN for emacs-devel@gnu.org; Thu, 20 May 2004 03:08:56 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BQhfc-0003Bw-Dq; Thu, 20 May 2004 03:08:48 -0400 Original-To: storm@cua.dk (Kim F. Storm) In-reply-to: (storm@cua.dk) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23762 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23762 Either we have to explicitly ensure that we never have any bogus pointer on the stack, e.g bzero all alloca'ed memory, or we must accept (i.e. ignore) bogus objects that we find via the stack. Since mark_memory cannot distinguish integer variables and C pointers from Lisp_Object variables, it will always be possible that some incorrect but apparently meaningful address appears in a stack slot. The design principle is that this should never cause an error or crash, it should at worst preserve some data that ought to be garbage. It looks like our code fails in many ways to follow that principle. When mark_object is compiled with GC_CHECK_MARKED_OBJECTS, it aborts when it finds a pointer that isn't meaningful. That is not right, but it indicates the wrong basic expectation is followed in marking. Marking a misc object sets the mark bit in it. If this supposed misc object isn't really other data, that will destroy the other data there. Likewise for symbols. With conservative stack marking, it would seem that using a mark bit inside an object is a bug, unless mark_object can first verify the object is real. mark_buffer seems to have a similar problem. I think GETMARKBIT has a similar problem, in that it assumes that the cons or float is contained in a real cons block or a real float block. It finds the address of that block by address calculations. If it found random data that points to a supposed cons cell in the wrong place, the address calculations will give an address that doesn't really correspond to a cons block. When it tries to find the mark bits of that block, it can crash on an invalid pointer, or even find a valid-looking pointer to other data and garble it.