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

[Andrea Corallo]

Pip Cet <pipcet@gmail.com> writes:

> On Mon, Mar 8, 2021 at 5:54 AM Pip Cet <pipcet@gmail.com> wrote:
>> Note that this might not always work because of conservative GC.
>
> If it doesn't work, can you simply retry a few times? Eventually there
> shouldn't be references to the stale native_comp_unit on the stack.
>
> However, I think I've worked out why dynlib_close doesn't do its job:
>
> Fnative_elisp_load creates a comp unit, but, if the shared library has
> already been initialized, it doesn't set that comp unit's comp_unit
> variable to point to the new comp unit; instead, it will continue
> pointing to the first comp unit which still has it open.
>
> Then, the original comp unit is unloaded but not the new one created
> by Fnative_elisp_load. We call dynlib_close() once, but we called it
> twice before, leaving the shared library open and initialized.
>
> Then, we try to load the comp unit again, and follow the stale
> comp_unit variable pointing to the original comp unit.
>
> Fix should be as attached. Note the fix is, at worst, harmless (unless
> I messed up), so we should apply it anyway just because it's good not
> to leave stale pointers lying around even if we hope that the OS
> unmaps them at some point.
>
> Pip

The original code was written in the assumption that dlclose (as
FreeLibrary) can't fail unloading a shared when the internal refcount
goes to zero.  As this is not the case I think the suggested patch is
the correct fix.

I've installed it as 93f92cf1ba.

Thanks!

  Andrea