Re: GC bug investigation

[David Kastrup]

Richard Stallman <address@hidden> writes:

> [[[ 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.

I may be missing something here, but I thought that Emacs was using a
_conservative_ garbage collector by default.  That means that arbitrary
garbage may mistakenly be considered as being in-use because some
integer on the stack is misinterpreted as a pointer to it.

> 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.

If that is the case, then any code supposed to work in conjunction with
a conservative garbage collector has to able to deal with it.

-- 
David Kastrup