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

[Alan Mackenzie]

Hello, Eli.

On Tue, Apr 02, 2019 at 18:04:22 +0300, Eli Zaretskii wrote:
> > Date: Tue, 2 Apr 2019 11:25:37 +0000
> > From: Alan Mackenzie <address@hidden>

> > 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.

> The usual method of debugging such problems is described in etc/DEBUG,

Apologies, I didn't see this.  I read quite a bit of etc/DEBUG, but for
some reason completely missed the bit about GC problems.

> it basically uses the last_marked[] array.  You start with the object
> at last_marked[last_marked_index - 1], and go backwards (in circular
> manner), comparing the objects you find in the array with those you
> see in the call-stack frames that call mark_* functions.  Just be very
> careful when you print the objects; e.g., never use 'pp', because the
> function it calls cannot handle marked objects.

I'm having some difficult seeing the entire last_marked array with GDB.
I will try to find a solution in the GDB manual.

> If you already tried this, please ask more specific questions.

No, I hadn't.  I didn't know about last_marked.  I'll see if I can get
further with its help.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).