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

[Gerd Möllmann]

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

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