[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.
Re: GC and stack marking, Stefan Monnier, 2014/05/20
- Re: GC and stack marking,
Eli Zaretskii <=
- Re: GC and stack marking, Stefan Monnier, 2014/05/20
- Re: GC and stack marking, Eli Zaretskii, 2014/05/20
- Re: GC and stack marking, Stefan Monnier, 2014/05/20
- Re: GC and stack marking, Eli Zaretskii, 2014/05/20
- Re: GC and stack marking, Stefan Monnier, 2014/05/20
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21
- Re: GC and stack marking, Dmitry Antipov, 2014/05/21
- Re: GC and stack marking, Dmitry Antipov, 2014/05/21
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21