GC bug investigation

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]

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:

mark_object(A)
mark_vectorlike(B)
mark_object(B)
mark_object(clear-transient-map)

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]