Re: GC and stack marking

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org, Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Tue, 20 May 2014 09:44:05 -0400
> 
> > The short version of the question is: is it possible that a Lisp
> > object which is no longer referenced by anything won't be GC'ed
> > because it is marked by mark_stack due to some kind of coincidence?
> 
> Yes, of course, it's what makes a conservative marking conservative.

I have nothing against conservative, but this failure to GC is too
spectacular to ignore.

> > So the huge hash-table gets dumped into the emacs executable, and
> 
> That's bad luck, indeed.
> 
> > causes all kinds of trouble in the dumped Emacs.
> 
> But it shouldn't cause any trouble (other than extra memory use).

It does, due to all kinds of subtleties.  The result is that the
large_vectors linked list gets dumped with a pointer to a non-existent
memory, and the dumped Emacs then crashes on the first GC when it
tries to traverse that linked list.

> > If this can legitimately happen, then how can we make sure this
> > hash-table indeed gets GC'd before we dump Emacs?
> 
> First we should make sure that even if this table is not GC'd, Emacs
> behaves correctly.

Fabrice might have found a work-around, so there is hope.  I found a
way to kludge around it, but my solution is more fragile.

Otherwise, we probably have a bug that can appear in
> other situations.
> 
> - find where the spurious "reference" is coming from and add code to set
>   this reference to some other value

I think this is hopeless: I see this problem on a single system; two
others don't have it.  It's just some semi-random garbage somehwre on
the stack.