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

[Alan Mackenzie]

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.

These symbols with position are implemented as pseudovectors with type
PVEC_SYMBOL_WITH_POS and behave as ordinary symbols for all purposes,
except for when a warning message is being output, when the postion
supplies a correct file/line number for the message.

This works and works well.  However it causes an unacceptable slowdown in
Emacs (around 8 - 15 per cent).  I'm working on a fix for this, and have
made substantial progress.

The topic was discussed at length in emacs-devel starting November last
year in posts whose Subject: contained "scratch/accurate-warning-pos".

-- 
Alan Mackenzie (Nuremberg, Germany).