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

Previous Next

Package: emacs;

Reported by: Andy Moreton <andrewjmoreton <at> gmail.com>

Date: Tue, 2 Feb 2021 11:12:02 UTC

Severity: normal

Done: Andrea Corallo <akrl <at> sdf.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com, Andrea Corallo <akrl <at> sdf.org>
Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree
Date: Mon, 8 Mar 2021 13:52:49 +0000
On Mon, Mar 8, 2021 at 1:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sun, 7 Mar 2021 22:16:58 +0000
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> > > If the CU was GC'ed the eln should have been dlclosed.
> >
> > Wait, I thought this was on Windows?
>
> Yes, and...?

No dlclose() on Windows. FreeLibrary() is documented to behave
differently from dlclose(), and I don't have a Windows system to test
whether it's actually different in practice.

> > > 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.
>
> Why would any of the above assumptions be violated?

I have several suspicions, including "because the second compilation
unit referring to the same handle hasn't been collected". Because that
is definitely a bug, and one we should fix, and then we can debug this
issue more if and when it reappears.

Pip




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.