Re: scratch/igc 90e80a9a53e 6/6: Adjust igc.c code to header changes

[Eli Zaretskii]

> Date: Sun, 21 Jul 2024 11:42:41 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: emacs-devel@gnu.org
> 
> > Error: error ("Memory exhausted--use M-x save-some-buffers then exit and 
> > restart Emacs")
> > dump-emacs-portable("d:/gnu/git/emacs/feature/src/bootstrap-emacs.pdmp")
> > 
> > The last commit that did build was 55670e0.
> 
> Thanks for letting me know! It builds here on 32-bit and 64-bit GNU/Linux 
> systems, so it's possible this is a Windows issue...

Maybe, maybe not.  I see nothing specific to Windows yet.

> > The backtrace from the call to memory_full is below. The reason seems
> > to be the recent changes in igc_dump_finish_obj: the result is that
> > dump_igc_finish_obj wants to write a preposterously large amount of
> > zeros into the dump: 744MB in the backtrace below, but I've seen much
> > larger numbers there, like 1.2GB(!). This causes dump_grow_buffer
> > requests 2GB from the OS, which rightfully fails.
> 
> That all points to an object with a broken MPS header (or none). The question 
> is what kind of object.
> 
> > #8 dump_float (lfloat=<optimized out>, ctx=<optimized out>) at 
> > pdumper.c:2381
> > 
> > #9 dump_object (ctx=0x724eb38, ctx@entry=0x724eb3c, object=XIL(0xcbf005))
> > at pdumper.c:3306
> 
> This section puzzles me. If object is a vectorlike (the type bits of 0xcbf005 
> are 5, so it should be), it should be dumped as a vectorlike, not a float.

Does the below help?

  #4  dump_write (ctx=0x71ceb38, buf=0x71ce848, nbyte=8) at pdumper.c:792
  792     dump_write (struct dump_context *ctx, const void *buf, dump_off nbyte)
  (gdb) p ctx->igc_obj_dumped
  $1 = (void *) 0xc3f000 <Sinternal_show_cursor_p>

> (Also, ctx@entry shouldn't be different from ctx, should it?)

I think this is just GDB trying (and failing) to understand the
complexity of GCC's allocation of the place to hold the value:

  (gdb) fr 9
  #9  dump_object (ctx=0x71ceb38, ctx@entry=0x71ceb3c,
      object=0xc3f005 <Sinternal_show_cursor_p+5>) at pdumper.c:3306
  3306          offset = dump_float (ctx, XFLOAT (object));
  (gdb) info address ctx
  Symbol "ctx" is multi-location:
    Range 0x6d2df0-0x6d2e14: a variable in $eax
    Range 0x6d2e14-0x6d2f84: a variable in $ebx
    Range 0x6d2f84-0x6d2f88: a complex DWARF expression:
       0: DW_OP_GNU_entry_value
         2: DW_OP_reg0 [$eax]
       3: DW_OP_stack_value

    Range 0x6d2f88-0x6d2f8b: a variable in $eax
    Range 0x6d2f8b-0x6d300a: a variable in $ebx
    Range 0x6d300a-0x6d300e: a complex DWARF expression:
       0: DW_OP_GNU_entry_value
         2: DW_OP_reg0 [$eax]
       3: DW_OP_stack_value

    Range 0x6d300e-0x6d3bb5: a variable in $ebx
    Range 0x8a1c70-0x8a1c75: a variable in $ebx

>From poking inside igc_dump_finish_obj, the value returned by obj_size
here:

        return base + obj_size (h);

is preposterously large.