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

[Alan Mackenzie]

Hello again, Daniel.

On Tue, Apr 02, 2019 at 13:33:02 -0700, Daniel Colascione wrote:
> > Hello, Daniel.

> > On Tue, Apr 02, 2019 at 12:09:59 -0700, Daniel Colascione wrote:
> >> > 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?

> > It's to help solve a bug in the byte compiler, which up until recently
> > was intractable.  The byte compiler frequently (?usually) reports
> > incorrect line/column numbers in its warning messages.  This is due to
> > the kludge it uses to keep track of them.

> > The only current candidate for a fix is for the reader, on a flag being
> > bound to non-nil, to return "symbols with position" rather than standard
> > symbols.  The "position" associated with the symbol is it's textual
> > offset from the beginning of the construct in the source file being read.

> So if I read symbol foo from file1.el and symbol foo from file2.el, I get
> two different symbol-with-location instances, each tagged with a different
> source location? Do these symbol objects compare eq to each other?

They do, yes.  Otherwise the byte compiler wouldn't work, as it
frequently compares a symbol-with-position with a constant ("ordinary")
symbol using eq.

However, it is envisaged the flag symbols-with-pos-enable will be bound
to non-nil only by the byte compiler.  The reader resets this position to
zero for each top-level form it reads.

-- 
Alan Mackenzie (Nuremberg, Germany).