Re: Fix to long-standing crashes in GC

[Richard Stallman <rms@gnu.org>]

    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.