GNU bug report logs -
#46256
[feature/native-comp] AOT eln files ignored if run from build tree
Previous Next
Full log
View this message in rfc822 format
Pip Cet <pipcet <at> 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 <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 :-)
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
This bug report was last modified 4 years and 129 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.