Re: Fix to long-standing crashes in GC

[storm@cua.dk (Kim F. Storm)]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

I removed my hack to accept Lisp_Misc_Free objects (to better
understand where the problem originated), and then emacs crashed
there...  so GDB lead me 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.

Yes, that works 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.

I have now found two different cases where a pointer on the stack
points to GC-managed memory (mem_find finds it), to a cons cell with a
Lisp_Misc_Free in the car and a bogus list in the cdr.  I suspect there
are many more such cases.

I included one such list in my previous mail.  So even if we accepted
the Lisp_Misc_Free object (as I said, I reverted that change locally to
understand the problem), following the cdr would lead to a bad Misc
object anyway.

> 
> So I think w need to look further.

Looking for what? 

More proff that current functionality is broken, or ways to fix it?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk