[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Help please! To track down GC trying to free an already freed object.
From: |
Alan Mackenzie |
Subject: |
Help please! To track down GC trying to free an already freed object. |
Date: |
Tue, 2 Apr 2019 11:25:37 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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).