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

[Pip Cet <pipcet@gmail.com>]

On Sun, Mar 7, 2021 at 9:51 PM Andrea Corallo <akrl@sdf.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
> > On Sun, Mar 7, 2021 at 8:17 PM Andrea Corallo via Bug reports for GNU
> > Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org>
> > wrote:
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> >> From: Andrea Corallo <akrl@sdf.org>
> >> >> Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com
> >> >> Date: Sun, 07 Mar 2021 18:53:50 +0000
> >> What I think is going on here:
> >>
> >> The same .eln file is loaded two times, we detect that and try to reuse
> >> the same compilation unit (the Lisp object) instead of a new one.
> >>
> >> We keep a pointer to the compilation unit representing the .eln file in
> >> each .eln.  Here we read it and we have it into 'saved_cu', we try to
> >> dereference it and extract the CU with XNATIVE_COMP_UNIT but something
> >> goes wrong.
> >>
> >> This object might have been GC'ed for some reason and we might be
> >> looking at the same GC issue I've seen on 32bit wide-int (my guess).
> >> *If* this is the case the question is: why is the CU GC'ed?
> >
> > Why wouldn't it be? I'm trying to follow along here :-)
>
> If the CU was GC'ed the eln should have been dlclosed.

Wait, I thought this was on Windows?

> If that's the
> case at the next load we should get a fresh handle

You're assuming
1. FreeLibrary() succeeded
2. The module's refcount was 1
3. The module wasn't pinned.

If any of these assumptions is violated, the behavior would be
precisely as observed.

It's easy enough to test this: we can put a printf in dynlib_open
which tells us whether we see the same handle more than once.

> and 'saved_cu' should
> be NULL (ops!  Qnil... :/) because static allocated.

Well, for one reason or another, it wasn't reset to Qnil.

> Here what we see is that we are loading two times without dlclosing and
> the object pointed by 'cu_saved' has some issue.

I don't think so. I think we called dynlib_close(), it didn't actually
unmap the library, and everything else follows.

> So thinking about: the fact that the eln was never dlclosed should be
> prove that the CU was not GC'ed and so I was wrong.

I don't think you were wrong.

Pip