[Top][All Lists]

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

Re: GC bug investigation

From: David Kastrup
Subject: Re: GC bug investigation
Date: Sun, 23 Mar 2014 16:15:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

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

reply via email to

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