Re: GC and stack marking

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  fabrice.popineau@gmail.com
> Date: Wed, 21 May 2014 13:40:21 -0400
> 
> > I already tried that before, and came up empty-handed.  I tried again
> > now; the address of that value on the stack does not correspond to any
> > local variable in the corresponding stack frame, and I also cannot
> > find that address in the disassembly of the function whose stack frame
> > includes the value.
> 
> It might simply be a slot that's unused by the current stack frame,
> whose value comes from some stack frame that existed some time in
> the past.

That's probably what it is, yes.

> Which stack frame is that?

The one of Fgarbage_collect.  That's why I asked about mark_stack
looking for objects too high on the stack.

> > Now, I have a question: mark_stack stops examining the stack when it
> > gets to its own stack frame.  That is certainly safe, but it sounds
> > too conservative: it should stop at the stack frame of
> > Fgarbage_collect, I think, because no live Lisp object can appear
> > while Fgarbage_collect runs, right?
> 
> Sounds right, yes.

I will try that and see if that helps.  Of course, if my reading of
GDB data is correct, and the value was indeed in the
Fgarbage_collect's stack frame, it must help.