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: 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: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree
Date: Mon, 08 Mar 2021 20:06:58 +0200
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Mon, 8 Mar 2021 14:27:19 +0000
> Cc: Andrea Corallo <akrl <at> sdf.org>, 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> 
> I would be interested in the pseudovector type of the variable that is
> supposed to be a comp_unit, but isn't. I think that's all the
> information of value that debuggee still has...

You mean, *saved_cu?  It cannot be anything interesting, because the
pointer is garbled:

  (gdb) p *saved_cu
  $9 = XIL(0x6f04860091b9000)
  (gdb) xtype
  Lisp_Symbol
  (gdb) xsymbol
  $10 = (struct Lisp_Symbol *) 0xaa21360
  Cannot access memory at address 0xaa21368

Since this is a 32-bit build, no Lisp object can have the high 24 bits
non-zero, so 0x6f04860091b9000 cannot be a valid object.

Another factoid that may be of interest is this.  At the beginning of
load_comp_unit we do:

  dynlib_handle_ptr handle = comp_u->handle;

So:

  (gdb) p/x comp_u->handle
  $13 = 0x6a580000

Now, on Windows, the "handle" returned by LoadLibrary is just the
memory address where the library is loaded.  However, "info shared" in
GDB doesn't show _any_ .eln library loaded at that address.  The
closest one is this:

  From        To          Syms Read   Shared Object Library
  0x6a581000  0x6a5bacd8  Yes         d:\usr\eli\.emacs.d\eln-cache\28.0.50-19fa14f1\cc-align-bb265728-bd3550a3.eln

whose address is 4KB higher.  That probably means the CU represented
by comp_u was unloaded, right?

Anything else we could glean from that crashed Emacs?




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.