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

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

Pip Cet <pipcet <at> gmail.com> writes:

> On Mon, Mar 8, 2021 at 10:14 AM Andrea Corallo <akrl <at> sdf.org> wrote:
>> Hi Pip,
>>
>> thanks for the analysis, I'm not sure I followed 100% so I'll repeat to
>> make sure we are on the same page, please correct me in case.
>
> Thanks for that!
>
>> IIUC (and make sense to me) the issue is that we are leaving two pointer
>> pointing to the same handle: One is in the CU_2 allocated by
>> 'Fnative_elisp_load' and later discarded by 'load_comp_unit' when
>> reloading the same filename.  The other is the original CU_1 created the
>> first time this filename was loaded.
>>
>> When CU_2 will be GC'ed because discarded we'll get the problem because
>> we'll dlclose the handle.  Is this correct?
>
> CU_1 is GC'ed first. CU_2, for whatever reason, isn't  GC'ed in the same cycle.
>
>> In case isn't the attached curing the issue as well?
>
> I don't think so. The problem is that we have an invalid Lisp_Object
> in the shared library, not that we're calling dlclose() too often..
>
> Again, there's no real cost to fixing this: at best, we avoid a
> catastrophic use-after-free. At worst, we nulled out a word of memory
> only for it to be unmapped a moment later, no harm done.
>
>> PS I couldn't reproduce using the lisp reproducer both on my 64bit both
>> on my 32bit system (I left it looping for a while), is that reproducer
>> working for you?
>
> Have you modified dynlib_open() to leak the shared object? That's what
> I think might be happening for Eli, so it makes sense to test with a
> double dlopen() call, as I did.

No, because I failed to understand why calling 'dlopen' two times in a
row on the same filename should make any difference as I expect the
second call to just return the same handle as the first.

I'm sure I'm missing something here or I misunderstood your suggestion:

> I can reproduce this issue by replacing the single call of dlopen() in
> dynlib_open with two calls


Thanks

  Andrea

Previous Next

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