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
Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree
Date: Mon, 08 Mar 2021 17:07:30 +0200

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> Date: Sun, 07 Mar 2021 20:16:40 +0000
> 
> >   #1  0x0135a63b in emacs_abort () at w32fns.c:10914
> >   #2  0x0115c637 in terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
> >       at emacs.c:417
> >   #3  0x0121c026 in die (msg=0x1782af2 <targets+1266> "NATIVE_COMP_UNITP (a)",
> >       file=0x1782aeb <targets+1259> "comp.h", line=70) at alloc.c:7452
> >   #4  0x012cf582 in XNATIVE_COMP_UNIT (a=XIL(0x6f04860091b9000)) at comp.h:70
> >   #5  0x012df324 in load_comp_unit (comp_u=0x6f33918, loading_dump=false,
> >       late_load=false) at comp.c:4821
> >   #6  0x012e0c55 in Fnative_elisp_load (filename=XIL(0x80000000092db190),
> >       late_load=XIL(0)) at comp.c:5122
> 
> 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?

Can you please step back a notch for a moment and help me understand
how this machinery works?  Because I'm looking at the code, and I'm
confused.

For example, I see this:

  Lisp_Object *saved_cu = dynlib_sym (handle, COMP_UNIT_SYM);
  comp_u->loaded_once = !NILP (*saved_cu);

But dynlib_sym doesn't return a pointer to a Lisp_Object, it returns a
pointer to a function or a variable inside the .eln shared library.
So how is this TRT?

A few lines later we do this:

      comp_u_lisp_obj = *saved_cu;
      comp_u = XNATIVE_COMP_UNIT (comp_u_lisp_obj);

But if saved_cu is NOT a pointer to a Lisp_Object, then how do we
expect XNATIVE_COMP_UNIT not to crash?

What am I missing?

Previous Next

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