Re: MPS: unable to build due to assertion violation in igc_dump_check_object_starts

[Eli Zaretskii]

> Date: Tue, 23 Jul 2024 21:00:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: pipcet@protonmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org
> 
>   #1  0x00c9febf in dump_igc_finish_obj (ctx=0x777eb38, ctx@entry=0x777eb3c)
>       at pdumper.c:935
>   935             emacs_abort ();
>   (gdb) bt
>   #0  emacs_abort () at w32fns.c:11335
>   #1  0x00c9febf in dump_igc_finish_obj (ctx=0x777eb38, ctx@entry=0x777eb3c)
>       at pdumper.c:935
>   #2  0x00ca5a3f in dump_cold_string (string=<optimized out>, ctx=0x777eb3c)
>       at pdumper.c:3560
>   #3  dump_drain_cold_data (ctx=0x777eb3c) at pdumper.c:3714
>   #4  Fdump_emacs_portable (filename=<optimized out>,
>       track_referrers=<optimized out>) at pdumper.c:4514
>   #5  0x00ccae36 in eval_sub (form=0xbb2ac73) at eval.c:2630
>   #6  0x00ccac41 in eval_sub (form=0xbb2abb3) at eval.c:2578
>   #7  0x00ccafc3 in Fprogn (body=0xbb2ae6b) at eval.c:452
>   #8  0x00ccc068 in Flet (args=<optimized out>) at lisp.h:1546
>   #9  0x00ccac41 in eval_sub (form=0xbb2aacb) at eval.c:2578
>   #10 0x00ccc916 in Funwind_protect (args=0xbb2ae7b) at lisp.h:1546
>   #11 0x00ccac41 in eval_sub (form=0xbb2aabb) at eval.c:2578
>   #12 0x00ccafc3 in Fprogn (body=0x0) at eval.c:452
>   #13 0x00ccc068 in Flet (args=<optimized out>) at lisp.h:1546
>   #14 0x00ccac41 in eval_sub (form=0xbb2aa8b) at eval.c:2578
>   #15 0x00ccafc3 in Fprogn (body=0xbb2b93b) at eval.c:452
>   #16 0x00ccc068 in Flet (args=<optimized out>) at lisp.h:1546
>   #17 0x00ccac41 in eval_sub (form=0xbb2a52b) at eval.c:2578
>   #18 0x00ccac41 in eval_sub (form=0xbb2a50b) at eval.c:2578
>   #19 0x00ccafc3 in Fprogn (body=0x0) at eval.c:452
>   #20 0x00ccac41 in eval_sub (form=form@entry=0xbb29ff3) at eval.c:2578
>   #21 0x00d06f34 in readevalloop (readcharfun=readcharfun@entry=0x60c0,
>       infile0=infile0@entry=0x777f638, sourcename=sourcename@entry=0xa848184,
>       printflag=printflag@entry=false, unibyte=unibyte@entry=0x0,
>       readfun=readfun@entry=0x0, start=start@entry=0x0, end=<optimized out>,
>       end@entry=0x0) at lread.c:2537
>   #22 0x00d0798b in Fload (file=<optimized out>, noerror=0x0, nomessage=0x0,
>       nosuffix=0x0, must_suffix=<optimized out>) at lisp.h:1214
>   #23 0x00ccadd3 in eval_sub (form=form@entry=0xa847e4b) at eval.c:2641
>   #24 0x00cccf0d in Feval (form=0xa847e4b, lexical=lexical@entry=0x20)
>       at eval.c:2486
>   #25 0x00c25d51 in top_level_2 () at lisp.h:1214
>   #26 0x00cc528c in internal_condition_case (
>       bfun=bfun@entry=0xc25cf3 <top_level_2>, handlers=handlers@entry=0x60,
>       hfun=hfun@entry=0xc2f806 <cmd_error>) at eval.c:1633
>   #27 0x00c26460 in top_level_1 (ignore=0x0) at lisp.h:1214
>   #28 0x00cc51a6 in internal_catch (tag=tag@entry=0xc520,
>       func=func@entry=0xc26437 <top_level_1>, arg=arg@entry=0x0) at 
> eval.c:1312
>   #29 0x00c25b0f in command_loop () at lisp.h:1214
>   #30 0x00c2f3c4 in recursive_edit_1 () at keyboard.c:765
>   #31 0x00c2f6b2 in Frecursive_edit () at keyboard.c:848
>   #32 0x00e75745 in main (argc=<optimized out>, argv=<optimized out>)
>       at emacs.c:2646
>   (gdb) up
>   #2  0x00ca5a3f in dump_cold_string (string=<optimized out>, ctx=0x777eb3c)
>       at pdumper.c:3560
>   3560      dump_igc_finish_obj (ctx);
>   (gdb) p data
>   $1 = (struct Lisp_String_Data *) 0xb52b200
>   (gdb) p *$
>   $2 = {gc_header = {v = 245077557021}, data = 0xb52b208 
> "ÅÆ!\210Ç\030\t.\017"}
>   (gdb) p/x *$1
>   $3 = {gc_header = {v = 0x390fc2bf1d}, data = 0xb52b208}
>   (gdb)

And:

  (gdb) fr 1
  #1  0x00c9febf in dump_igc_finish_obj (ctx=0x777eb38, ctx@entry=0x777eb3c)
      at pdumper.c:935
  935             emacs_abort ();
  (gdb) p ctx->igc_type
  $5 = IGC_OBJ_STRING_DATA
  (gdb) p should_end
  $6 = <optimized out>
  (gdb) p ctx->igc_obj_dumped
  $7 = (void *) 0xb52b200
  (gdb) p igc_header_type(ctx->igc_obj_dumped)
  $8 = IGC_OBJ_STRING_DATA
  (gdb) p obj_size(ctx->igc_obj_dumped)
  $9 = 112

So this is IGC_OBJ_STRING_DATA, but why doesn't igc_dump_finish_obj do
its job in this case?  What are we missing?