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

[Eli Zaretskii <eliz@gnu.org>]

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

  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?

Let me know if I can collect more data.