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

["Daniel Colascione" <dancol@dancol.org>]

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