On Sunday, July 21st, 2024 at 12:07, Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.

If it is what I think it is, I'm surprised I haven't seen it in my tests, as it's not specific to Windows at all.

> > > 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>

Thanks, that helps a lot! It's an internal subr, and those don't store their proper size in the pseudovector header, so we don't dump them properly as we trust the pseudovector header.

I've managed to reproduce something similar here, and the attached patch helps, but it probably breaks GC in the !HAVE_MPS case.

> > (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:

That makes sense, yes.

Thanks again
Pip