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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com, pipcet <at> gmail.com
Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree
Date: Tue, 09 Mar 2021 18:51:03 +0200

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: pipcet <at> gmail.com, 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> Date: Tue, 09 Mar 2021 15:38:54 +0000
> 
> > I've now built the latest branch.  It still crashes, in the same
> > place, although with different Lisp files.  I'm looking into this,
> > will post the details.
> 
> Thinking about, you might have stale eln files reachable in the
> `comp-eln-load-path' generated with the bug fixed by 380ba045c4.

Maybe.  What I see is that we load a CU in Fnative_elisp_load followed
by load_comp_unit, for the first time, and create a Lisp CU object for
it:

  Lisp_Object comp_u_lisp_obj;
  XSETNATIVE_COMP_UNIT (comp_u_lisp_obj, comp_u);

Then we store it in the shared library:

  if (comp_u->loaded_once)
    ...
  else
    *saved_cu = comp_u_lisp_obj;

But then we clobber the value of comp_u_lisp_obj here:

	  data_ephemeral_vec =
	    load_static_obj (comp_u, TEXT_DATA_RELOC_EPHEMERAL_SYM);

	  EMACS_INT d_vec_len = XFIXNUM (Flength (data_ephemeral_vec));
	  for (EMACS_INT i = 0; i < d_vec_len; i++)
	    data_eph_relocs[i] = AREF (data_ephemeral_vec, i);  <<<<<<<<<<<

Is this likely to be due to that problem?

Previous Next

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