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

Previous Next

Full log

View this message in rfc822 format

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: bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
Date: Sun, 21 Aug 2022 10:50:11 +0200

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

>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>> 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.
>>

Sorry for following up again to myself, but I haven't lost the hope that
someone in the know chimes in at some point :-).

When I print the value that the window.eln compilation unit has in
objects_dumped

(lldb) expr -- $299->key_and_value 
(Lisp_Object) $317 = 0x000000011004800d (struct Lisp_Vector *) $321 = 0x0000000110048008
(lldb) expr -- $321->contents  [2*2010 + 1]
(Lisp_Object) $322 = 0xfffffffffffffffe (struct Lisp_Cons *) $324 = 0xfffffffffffffff8
(lldb) xdebug_print $321->contents  [2*2010 + 1]
-1

We see (a) my lldb support has a bug (shit), and (b) that the value is
-1, which is DUMP_OBJECT_ON_NORMAL_QUEUE.

And when I go a frame up in the callstack, I see indeed

frame #5: 0x000000010014cc24 temacs`dump_drain_normal_queue(ctx=0x000000016fdfe300) at pdumper.c:3985:5 [opt]
   3982	dump_drain_normal_queue (struct dump_context *ctx)
   3983	{
   3984	  while (!dump_queue_empty_p (&ctx->dump_queue))
-> 3985	    dump_object (ctx, dump_queue_dequeue (&ctx->dump_queue, ctx->offset));
   3986	}

Another frame up

frame #6: 0x000000010014b514 temacs`Fdump_emacs_portable(filename=<unavailable>, track_referrers=<unavailable>) at pdumper.c:4175:7 [opt]
   4172	    {
   4173	      dump_drain_deferred_hash_tables (ctx);
   4174	      dump_drain_deferred_symbols (ctx);
-> 4175	      dump_drain_normal_queue (ctx);
   4176	    }

So, I think what happens here is this:

Window.eln's compilation unit gets dumped normally the first time
around.  But it also is put on the dump_context::dump_queue for some
reason.  Add when the queue is processed, boom...

Hm again.

Previous Next

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