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

From: Andrea Corallo <[email-masked]>
Date: Mon, 08 Mar 2021 15:02:58 +0000

Pip Cet <[email-masked]> writes:

> On Mon, Mar 8, 2021 at 10:14 AM Andrea Corallo <[email-masked]> 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