[Top][All Lists]

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

GC bug investigation

From: Daniel Colascione
Subject: GC bug investigation
Date: Sat, 22 Mar 2014 18:58:17 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 03/22/2014 04:57 PM, Richard Stallman wrote:
> [[[ 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. ]]]
>     Richard, it would be very helpful if you could provide either a recipe
>     for reproducing your crash 
> I agree, it would be very helpful if I could.  But I can't.
>     or an actual crash dump (not your
>     paraphrasing of the stack trace).
> If someone tells me a GDB command to make one, maybe I can do so.

As Eli mentioned, you can use the "gcore" gdb command.

> hesitate to show it to anyone.  And I don't think it would be useful.

I understand; I'd also be hesitant to share a dump. But being able to
instruct you to examine the dump in various ways would be very useful,
especially if we add debug instrumentation.

> I don't think any more information can be extracted at the time
> it crashes.

Details of the objects on the path might be useful. In prior messages
about this bug, you focus on stack slots. I don't think that's useful,
as a conservative GC ought to operate properly using arbitrary inputs as
temporary roots.  I want to know exactly where we crash and in what
manner, as I explained on another thread.

For clarity: you mention "[the crash was in] mark_object called from
mark_vectorlike called from mark_object called from mark_object (marking
that symbol)." I interpret this text as meaning "some instruction in
mark_object faulted", with the top of the execution stack looking like this:


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. That
we're reaching B at all indicates that it shouldn't be dead.
clear-transient-map isn't dead either, although double-checking would be
nice. That's why the symbol_free_list->function = Vdead code did nothing.

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.

Can you try running with -DGC_CHECK_MARKED_OBJECTS=1 in your CFLAGS?

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.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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