[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GC and stack marking

From: Eli Zaretskii
Subject: Re: GC and stack marking
Date: Tue, 20 May 2014 19:57:01 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden, Fabrice Popineau <address@hidden>
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]