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

[Andrea Corallo]

Pip Cet <pipcet@gmail.com> writes:

> 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@gnu.org>
> wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >> From: Andrea Corallo <akrl@sdf.org>
>> >> Cc: 46256@debbugs.gnu.org, andrewjmoreton@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 :-)

If the CU was GC'ed the eln should have been dlclosed.  If that's the
case at the next load we should get a fresh handle and 'saved_cu' should
be NULL (ops!  Qnil... :/) because static allocated.

Here what we see is that we are loading two times without dlclosing and
the object pointed by 'cu_saved' has some issue.

So thinking about: the fact that the eln was never dlclosed should be
prove that the CU was not GC'ed and so I was wrong.  This suggests also
that before further talking stupid I'd better say I'm done for the day
:)

  Andrea