Re: Help please! To track down GC trying to free an already freed object.

[Daniel Colascione]

> Hello, Emacs.
>
> I get this problem after a recent merge of master into
> /scratch/accurate-warning-pos (my branch where I'm trying to implement
> correct source positions in the byte compiler's warning messages).  This
> was a large merge, including bringing in the portable dumper.
>
> Emacs aborts at mark_object L+179 (in alloc.c), because a pseudovector
> being freed already has type PVEC_FREE, i.e. has been freed already.
> This object is a "symbol with position", a type of pseudovector which
> doesn't yet exist outside of this scratch branch.

Out of curiosity, why do we need a new C-level type here?

> At a guess, I'm setting some data structure in the C code to a Lisp
> structure containing this object, but failing to apply static protection
> to this C variable.  Or something like that.
>
> This failure occurs during the byte compilation of .../lisp/registry.el
> in a make or make bootstrap.  The failure only occurs when this byte
> compilation is started as -batch from the command line.  So my use of
> GDB is from the command line, not within a running Emacs.
>
> With GDB, I can break at the creation of this symbol-with-position
> object and again at its (first) freeing with this breakpoint:
>
>     break setup_on_free_list if (v == 0x5555561d0450)
>
> .  However, this isn't helping me to track down the Lisp object which
> still references this symbol-with-position.  I've tried to find the
> address of Emacs's data segment, so as to be able to search through it
> for 0x5555561d0455 in GDB, but this doesn't feel like a very useful
> thing to do.
>
> Could somebody who has experience in this sort of thing please suggest
> how I might proceed with the debugging, or possibly offer me some other
> sort of help or hints.
>
> Thanks in advance!

rr is incredibly helpful for debugging this sort of problem. See
https://rr-project.org/. You can record an rr session containing the
crash, replay it, get to the crash, and then reverse-next, reverse-finish,
and reverse-continue your way through the GC, running it in reverse until
you find whatever it is that made mark_object on the dead object happen.
Hardware watchpoints with rr are also very useful and work great in
reverse mode: just use watch -l myvar and reverse-continue to see who last
wrote a memory location, or use rwatch to see who last *read* a location.
(The -l is important since it enables the use of hardware watchpoints.)