[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Colascione
Subject: Re: Help please! To track down GC trying to free an already freed object.
Date: Tue, 2 Apr 2019 13:33:02 -0700
User-agent: SquirrelMail/1.4.23 [SVN]

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]