GNU bug report logs - #57309
29.0.50; Build error "trying to dump non fixed-up eln file"

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 57309 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#57309: 29.0.50; Build error "trying to dump non fixed-up
 eln file"
Date: Sat, 20 Aug 2022 17:08:53 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

>
> (lldb) p globals.f_Vcomp_loaded_comp_units_h 
> (Lisp_Object) $176 = 0x00000001040382b5 (struct Lisp_Hash_Table *) $181 = 0x00000001040382b0
> (lldb) p *$181
> (struct Lisp_Hash_Table) $182 = {
>   header = (size = 4611686018662313988)
>   weak = 0x000000000000fdb0 (struct Lisp_Symbol *) $185 = 0x00000001007d2b90
>   hash = 0x00000001042d10b5 (struct Lisp_Vector *) $189 = 0x00000001042d10b0
>   next = 0x00000001042d078d (struct Lisp_Vector *) $193 = 0x00000001042d0788
>   index = 0x00000001042d1605 (struct Lisp_Vector *) $197 = 0x00000001042d1600
>   count = 90
>   next_free = 90
>   purecopy = false
>   mutable = true
>   rehash_threshold = 0.8125
>   rehash_size = 0.5
>   key_and_value = 0x00000001042d0a9d (struct Lisp_Vector *) $201 = 0x00000001042d0a98
>   test = {
>     name = 0x00000000000060c0 (struct Lisp_Symbol *) $204 = 0x00000001007c8ea0
>     user_hash_function = NULL
>     user_cmp_function = NULL
>     cmpfn = 0x000000010017ed70 (temacs`cmpfn_equal at fns.c:4235)
>     hashfn = 0x000000010017ed9c (temacs`hashfn_equal at fns.c:4266)
>   }
>   next_weak = NULL
> }
> (lldb) xdebug_print $176
> ...lots of output...
>  "/Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln" #<native compilation unit: /Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln ((native-comp-speed . 2) (native-comp-debug . 0) (gccjit 12 1 0))>
> ...
>
> I'm not 100% sure, but I interpret that as meaning that the window.eln
> in question has already been loaded before, and the second attempt then
> fails.  Unless I misread the code of course, which is always possible.
>
> But how that might happen escapes me ATM.

And a little bit more...

The error "trying to..." comes from dump_native_comp_unit, which is
called from dump_vectorlike, which is called from dump_object.  Dumped
objects are recorded in a hashtable dump_context::objects_dumped.  Now

(lldb) p ctx->objects_dumped
(Lisp_Object) $294 = 0x000000010407373d (struct Lisp_Hash_Table *) $299 = 0x0000000104073738
(lldb) expr -- hash_lookup ($299, lv, 0)
(ptrdiff_t) $300 = 2010
(lldb) p lv
(Lisp_Object) $301 = 0x00000001040d0a6d (struct Lisp_Native_Comp_Unit *) $306 = 0x00000001040d0a68

lv is the compilation unit in question which gives the error, and the
dumpcontext says it is already dumped.

So what now?

I'd say one can encounter the same Lisp_Object more than once in a dump,
in general.  Shouldn't there be some check somewhere in the CU code?
Where is it?  Or is this supposed not to happen?  If so, how is it
ensured?

Questions over questions...

Previous Next

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