GNU bug report logs - #46256
[feature/native-comp] AOT eln files ignored if run from build tree

Previous Next

Full log

Message #373 received at 46256 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, andrewjmoreton <at> gmail.com,
 46256 <at> debbugs.gnu.org
Subject: Re: bug#46256: [feature/native-comp] AOT eln files ignored if run
 from build tree
Date: Sun, 7 Mar 2021 21:27:57 +0000

[Message part 1 (text/plain, inline)]

On Sun, Mar 7, 2021 at 8:17 PM Andrea Corallo via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org>
wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> From: Andrea Corallo <akrl <at> sdf.org>
> >> Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> >> Date: Sun, 07 Mar 2021 18:53:50 +0000
> What I think is going on here:
>
> The same .eln file is loaded two times, we detect that and try to reuse
> the same compilation unit (the Lisp object) instead of a new one.
>
> We keep a pointer to the compilation unit representing the .eln file in
> each .eln.  Here we read it and we have it into 'saved_cu', we try to
> dereference it and extract the CU with XNATIVE_COMP_UNIT but something
> goes wrong.
>
> This object might have been GC'ed for some reason and we might be
> looking at the same GC issue I've seen on 32bit wide-int (my guess).
> *If* this is the case the question is: why is the CU GC'ed?

Why wouldn't it be? I'm trying to follow along here :-)

What I'm thinking is the CU got GC'ed, which is perfectly okay, but we
never set its COMP_UNIT_SYM pointer to Qnil. Then we dlopen() the same
file again, get the old handle, read the stale COMP_UNIT_SYM pointer,
and dereference it.

We should verify that the CU is indeed a different PVEC type now
(ideally, PVEC_FREE), and then do something like the attached patch,
shouldn't we?

Pip

[0001-Fix-a-GC-issue-bug-46256.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.