Re: MPS: Forwording symbols

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 18 Jun 2024 20:33:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
> 
> > Can you access it after calling igc_postmortem?  Maybe barriers
> > work differently on Windows.
> 
> No idea if this helps, but here's what I get then:
> 
>   #0  igc_on_pdump_loaded (dump_base=dump_base@entry=0xb000008,
>       hot_start=hot_start@entry=0xb000080, hot_end=0xb585408,
>       cold_start=0xb5b0008, cold_end=cold_end@entry=0xba8b6c8,
>       cold_user_data_start=0xb7038c0, heap_end=0xb707b10) at igc.c:3769
>   3769      eassert (((struct igc_header *)cold_start)->obj_type
>   (gdb) p ((struct igc_header *)cold_start)->obj_type
>   Cannot access memory at address 0xb5b0008
>   (gdb) call igc_postmortem()
> 
>   Thread 5 received signal SIGTRAP, Trace/breakpoint trap.
>   [Switching to Thread 60368.0xb908]
>   0x77c79031 in ntdll!DbgBreakPoint () from C:\WINDOWS\SysWOW64\ntdll.dll
>   The program received a signal in another thread while
>   making a function call from GDB.
>   Evaluation of the expression containing the function
>   (igc_postmortem) will be abandoned.
>   When the function is done executing, GDB will silently stop.
>   (gdb) c
>   Continuing.
>   [Thread 60368.0xb908 exited with code 0]
> 
>   Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
>   [Switching to Thread 60368.0xcaa8]
>   0x774996c3 in KERNELBASE!DebugBreak () from C:\WINDOWS\SysWOW64\KernelBase.dll
>   (gdb) thread 1
>   [Switching to thread 1 (Thread 60368.0xcaa8)]
>   #0  0x774996c3 in KERNELBASE!DebugBreak ()
>      from C:\WINDOWS\SysWOW64\KernelBase.dll
>   (gdb) bt
>   #0  0x774996c3 in KERNELBASE!DebugBreak ()
>      from C:\WINDOWS\SysWOW64\KernelBase.dll
>   #1  0x0092477c in emacs_abort () at w32fns.c:11279
>   #2  0x007d4c70 in terminate_due_to_signal (sig=sig@entry=22,
>       backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:481
>   #3  0x009032bf in igc_assert_fail (
>       file=0xdfce76 <__mon_yday+45622> "protw3.c", line=36,
>       msg=0xdf1c80 <__mon_yday+64> "unreachable code") at igc.c:82
>   #4  0x009f9d53 in mps_lib_assert_fail (
>       condition=0xdf1c80 <__mon_yday+64> "unreachable code", line=36,
>       file=0xdfce76 <__mon_yday+45622> "protw3.c") at mpsliban.c:87
>   #5  ProtSet (base=0xb590000, limit=0xb591000, mode=0) at protw3.c:36
>   #6  ProtSet (base=0xb590000, limit=0xb591000, mode=0) at protw3.c:19
>   #7  0x009f9f70 in arenaExpose (arena=0x9220000) at traceanc.c:588
>   #8  ArenaPostmortem (globals=0x9220008) at traceanc.c:617
>   #9  0x009fa035 in mps_arena_postmortem (arena=<optimized out>) at mpsi.c:292
>   #10 0x0090530d in igc_postmortem () at igc.c:3612
>   #11 <function called from gdb>
>   #12 igc_on_pdump_loaded (dump_base=dump_base@entry=0xb000008,
>       hot_start=hot_start@entry=0xb000080, hot_end=0xb585408,
>       cold_start=0xb5b0008, cold_end=cold_end@entry=0xba8b6c8,
>       cold_user_data_start=0xb7038c0, heap_end=0xb707b10) at igc.c:3769
>   #13 0x008571b8 in pdumper_load (dump_filename=<optimized out>,
>       argv0=<optimized out>,
>       argv0@entry=0xacf0850 "d:\\gnu\\git\\emacs\\feature\\src\\emacs.exe")
>       at pdumper.c:6051
>   #14 0x00a19ae5 in load_pdump (dump_file=<optimized out>, argv=0x93325d0,
>       argc=<optimized out>) at emacs.c:991
>   #15 main (argc=<optimized out>, argv=<optimized out>) at emacs.c:1443
>   (gdb)
> 
> IOW, the call to igc_postmortem itself hits assertion violation.

Btw, the "unreachable" code in this case is this:

  void ProtSet(Addr base, Addr limit, AccessSet mode)
  {
    DWORD newProtect;
    DWORD oldProtect;

    AVER(base < limit);
    AVER(base != 0);
    AVERT(AccessSet, mode);

    newProtect = PAGE_EXECUTE_READWRITE;
    if((mode & AccessWRITE) != 0)
      newProtect = PAGE_EXECUTE_READ;
    if((mode & AccessREAD) != 0)
      newProtect = PAGE_NOACCESS;

    if(VirtualProtect((LPVOID)base, (SIZE_T)AddrOffset(base, limit),
		      newProtect, &oldProtect) == 0)
      NOTREACHED; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  }

It means that VirtualProtect failed.  Since 'mode' is zero, it means
the function was called to remove protection from the mmemory block,
and it failed, probably because the specified memory region was out of
the program's address space?