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

[Alan Mackenzie <acm@muc.de>]

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.

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!

-- 
Alan Mackenzie (Nuremberg, Germany).