Re: address@hidden: Re: Fix to long-standing crashes in GC]

[gerd . moellmann]

> From: Richard Stallman <address@hidden>
> To: address@hidden (Kim F. Storm)
> In-reply-to: <address@hidden> (address@hidden)
> Date: Thu, 20 May 2004 03:08:48 -0400
> Cc: address@hidden, address@hidden
> Subject: Re: Fix to long-standing crashes in GC
> Reply-To: address@hidden
> Sender: address@hidden
> 
>     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.

Correct.  Blocks of memory allocated for Lisp objects are inserted into
a red-black tree
for that purpose. The tree is searched for the integer found on the
stack, and we can tell 
from the result of the search if the integer is indeed a (potential)
reference to a live Lisp 
object, or if it is some random bit-pattern.

> 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.

I can't say much to these details, I'm afraid. I don't think I've ever
heard
of GETMARKBIT, for instance.