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

[Pip Cet]

On Mon, Mar 8, 2021 at 3:31 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Andrea Corallo <akrl@sdf.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 46256@debbugs.gnu.org,
> >         andrewjmoreton@gmail.com
> > Date: Sun, 07 Mar 2021 21:51:15 +0000
> >
> > > Why wouldn't it be? I'm trying to follow along here :-)
> >
> > If the CU was GC'ed the eln should have been dlclosed.  If that's the
> > case at the next load we should get a fresh handle and 'saved_cu' should
> > be NULL (ops!  Qnil... :/) because static allocated.
> >
> > Here what we see is that we are loading two times without dlclosing and
> > the object pointed by 'cu_saved' has some issue.
> >
> > 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.  This suggests also
> > that before further talking stupid I'd better say I'm done for the day
> > :)
>
> Thanks.  Please tell me if you need me to provide some further data
> from this crashed session.  If not, I will end the debugging session

Do you have to end the crashed session to start a new one? I think we
should keep it open for a while longer (or create a core dump, if that
works?) and still try to test whether it's the
dynlib_close()-might-not-close bug.

> and will try to find a recipe for reproducing the crash, so we could
> see which of the guesses are true.

Here's what I did to reproduce the crash:
1. create a file "test.el":

;; -*- lexical-binding: t; -*-
(defun testfun (x)
  (1+ x))

2. Evaluate:

(require 'comp)
(native-elisp-load (native-compile "test.el"))
(testfun 3)
(fmakunbound 'testfun)
(garbage-collect)
(native-elisp-load (native-compile "test.el"))

Note that this might not always work because of conservative GC.

Pip