[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GC bug investigation
From: |
Richard Stallman |
Subject: |
Re: GC bug investigation |
Date: |
Sun, 23 Mar 2014 10:57:34 -0400 |
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Details of the objects on the path might be useful.
I don't understand "on the path".
mark_object(A)
mark_vectorlike(B)
mark_object(B)
mark_object(clear-transient-map)
Right.
B here is clear-transient-map's function cell, right? You're saying you
saw that it's a pseudovector that safe_debug_print reports as
INVALID_LISP_OBJECT, probably because live_vector_p returns 0.
Yes.
That
we're reaching B at all indicates that it shouldn't be dead.
I guess so. This is the mysterious part.
B must have been made dead *before* being assigned to
clear-transient-map's function cell. Looking at the bytecode in
set-transient-map, though, I don't see how that's possible.
I don't think that's what happened. If it were that, we would
see crashes when that code tries to _use_ the value legitimately.
clear-transient-map isn't dead either,
It has not been freed, it seems, but it may be garbage.
It is being marked through a spurious pointer randomly hanging around
in a stack slot for something else. We don't know that there is any
real pointer to it.
I don't think that writing code that aborts or breaks when a particular
vector is freed will be very helpful; we'll hit that code in normal
operation too. Instead, it'll probably be more useful to print a
backtrace (using emacs_backtrace) each time we see that vectorlike
freed, then look at the last backtrace before the GC crash.
Maybe you are right.
Can you try running with -DGC_CHECK_MARKED_OBJECTS=1 in your CFLAGS?
I can, but it would be a big pain. It takes many hours to recompile
Emacs on this machine.
What would it tell us? It would confirm that the vectorlike was freed,
perhaps, but do we doubt that?
If that hassle is likely to solve the problem, I'll do it,
but I'd rather not go to that hassle just to confirm what we know.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
- Re: Changes that should go into version 24.4, (continued)
- Re: Changes that should go into version 24.4, Daniel Colascione, 2014/03/21
- Re: Changes that should go into version 24.4, Eli Zaretskii, 2014/03/22
- Re: Changes that should go into version 24.4, Richard Stallman, 2014/03/22
- Re: GC bug investigation,
Richard Stallman <=
- Re: GC bug investigation, David Kastrup, 2014/03/23
- Re: GC bug investigation, Richard Stallman, 2014/03/24
- Re: GC bug investigation, Daniel Colascione, 2014/03/23
- Re: GC bug investigation, Andreas Schwab, 2014/03/23
- Re: GC bug investigation, Richard Stallman, 2014/03/24
- Re: GC bug investigation, Eli Zaretskii, 2014/03/23
- Re: Changes that should go into version 24.4, Eli Zaretskii, 2014/03/22