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

[Pip Cet <pipcet@protonmail.com>]

On Tuesday, July 23rd, 2024 at 14:26, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Gerd Möllmann gerd.moellmann@gmail.com
> 
> > Cc: Pip Cet pipcet@protonmail.com, Helmut Eller eller.helmut@gmail.com,
> > emacs-devel@gnu.org
> > Date: Tue, 23 Jul 2024 16:10:42 +0200
> > 
> > Eli Zaretskii eliz@gnu.org writes:
> > 
> > > So it looks like dflt_skip(0x1b26ac70) yields some bogus value, but I
> > > have no idea what it means or where to look to find the reason(s).
> > 
> > This function checks the consistency of the pdump when it is written. It
> > should be the case that the two regions of the dump (hot and cold)
> > contain igc_headers that correspond to the relocs that the pdump
> > contains.
> > 
> > With i == 1 we are currently in the cold region. It should be the case
> > that the igc_headers contained in the cold region are traversable in the
> > same way as if the objects in the region had been allocated from MPS.
> > That is, we start at the start of the regioni with the first objects,
> > then dftl_skip from there we reach the second object, dflt_skip from
> > there takes us to the third object and so on.
> > 
> > In the failing case, dflt_skip from p does not take us to the next
> > object, as far as the relocs say, So either the igc_header at p is
> > somehow wrong or the reloc entry from relocs is wrong.
> > 
> > Maybe one can see from the igc_header at p what object type was dumped
> > there? There should be some 32-bit dependency somewhwere since I don't
> > see that here on 64 bits.
> 
> I don't really understand what I'm doing, but does the below help?

That looks very helpful indeed. Thanks for testing this, I need to get a mingw development environment somehow...

> Thread 1 hit Breakpoint 1, emacs_abort () at w32fns.c:11335
> 11335 {
> (gdb) up
> #1 0x00eb5540 in terminate_due_to_signal (sig=sig@entry=22,
> backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:470
> 470 emacs_raise (sig);
> (gdb)
> #2 0x00f2a81a in die (msg=0x14f8051 <i_fwd+4017> "end == p",
> 
> file=0x14f79c8 <i_fwd+2344> "igc.c", line=4820) at alloc.c:8400
> 
> 8400 terminate_due_to_signal (SIGABRT, INT_MAX);
> (gdb)
> #3 0x00fee189 in igc_dump_check_object_starts (relocs=0x11d32853,
> dump_base=0x1aa41020, hot_start=0x1aa41098, hot_end=0x1b055c70,
> cold_start=0x1b081020, heap_end=0x1b1f9e98) at igc.c:4820
> 4820 eassert (end == p);
> (gdb) p obj_size(start)
> $1 = 801749580
> (gdb) p igc_header_nwords(start)
> $2 = 200437395
> (gdb) p header_tag(start)
> $3 = 0
> (gdb) p header_nwords(start)
> $4 = 200437395
> (gdb) p *(struct igc_header *)start
> $5 = {v = 1721744118644157000}
> (gdb) p/x *(struct igc_header *)start
> $6 = {v = 0x17e4dd2759e72a48}
> (gdb) p relocs
> $7 = (Lisp_Object) 0x11d32853
> (gdb) source .gdbinit
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
> Environment variable "DISPLAY" not defined.
> Environment variable "TERM" not defined.
> Breakpoint 2 at 0xeb54e0: file emacs.c, line 432.
> (gdb) p relocs
> $8 = XIL(0x11d32853)
> (gdb) xtype
> Lisp_Cons
> (gdb) xcar
> $9 = 0x11a5eda3
> (gdb) xtype
> Lisp_Cons
> (gdb) xcar
> $10 = 0x1b9b062
> (gdb) xtype
> Lisp_Int0
> (gdb) xint
> $11 = 7236632
> (gdb) p r
> $12 = XIL(0x11a5ed33)
> (gdb) xtype
> Lisp_Cons
> (gdb) xcar
> $13 = 0x1b9b022
> (gdb) xtype
> Lisp_Int0
> (gdb) xint
> $14 = 7236616
> (gdb) pp r
> (7236616 7236632)
> 
> So relocs seem to be pairs of numbers, and 'r', the one that seems to
> cause the problem, looks okay to me. But is the igc_header okay?

Definitely not.  No valid igc_header is divisible by four.

> Let me know if I can collect more data.

Will do once I have an idea.

Thanks again, and sorry for the trouble.

Pip