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

Previous Next

Full log

Message #400 received at 46256 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com, akrl <at> sdf.org
Subject: Re: bug#46256: [feature/native-comp] AOT eln files ignored if run
 from build tree
Date: Mon, 08 Mar 2021 15:26:27 +0200

> 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
> 
> > >> 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?

Yes, and...?

> > 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.