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

[Pip Cet]

On Mon, Mar 8, 2021 at 10:14 AM Andrea Corallo <akrl@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.

FWIW, I suspect the reproducer should crash with your patch applied,
but I can't test right now :-)

Thanks

Pip