Re: Fix to long-standing crashes in GC

[Stefan Monnier]

>> Please try finding out *precisely* which stack slot
>> mark_memory is currently examining.  Which stack frame is it in?
>> What variable is it?
>> 

> Found another case where a stack pointer points to bogus data,
> this time in Flet, variable *temps:

What do you mean by "found"?  Did you inspect the code looking for
suspicious things, or did GDB lead you there?

> Here we call Feval, which -- at some point in time will trigger GC --
> and "temps" is filled with random data, some of which are bogus Lisp
> object pointers.

If gcpros are used, it seems safe: the gcpro2.nvars is initially set to 0 so
none of the random values in the uninitialized `temps' array are considered
and then as the array gets filled gcpro2.nvars is incremented accordingly.
Looks fine.

If gcpros are not used (i.e. we use conservative stack scanning), it
shouldn't be a problem either because the conservative scan goes through
some trouble to ensure that it ignores words pointing to non-GC-managed
(or non-live) objects.

So I think w need to look further.


        Stefan