Re: Fix to long-standing crashes in GC

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

misc_live_p is supposed to make sure this never happens.

> 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_object is only called after checking that the presumed pointer does
point to a live object of the expected type.

> mark_buffer seems to have a similar problem.

And the same solution is applied.

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

That's what find_mem is for: to make sure it's indeed one of our cons
blocks or float block (and which of the two).

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

Only if there's a bug in the mem_find code.


        Stefan