GNU bug report logs -
#46256
[feature/native-comp] AOT eln files ignored if run from build tree
Previous Next
Full log
Message #418 received at 46256 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 4 years and 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.