Re: Unexec dumping results in "Segmentation fault" on Windows Msys2

[Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>]

Here's what I was able to gather in regards to this issue.

Whenever I'm trying to build master I get:
dumped_data_commit: memory exhausted.
Enlarge dumped_data[]!

Due to this I have to set DUMPED_HEAP_SIZE (24*1024*1024). Just 
mentioning this for completeness sake, that's not the issue here.

Segfaults are triggered by msys2 binutils version 2.36. If we try to 
debug the segfault with GDB we get this:

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff7c7514862 in main (argc=9, argv=0x1f815ad1860)
     at D:/Emacs/source/repo/src/emacs.c:960
960       stack_bottom = (char *) &stack_bottom_variable;

It seems like the initial bootstrap-emacs.exe is so broken that it fails 
at even the simplest things. The question I keep asking myself is, if we 
assume that it's our build environment that has some problem, why is 
unexec the only place that is harmed by it? Would it be possible to come 
up with some isolated test case that would demonstrate the problem? Then 
maybe it can be submitted to msys2 or mingw64 developers.

Now, lets downgrade binutils to version 2.35(or older), you can do that 
by grabbing the archive from here( https://repo.msys2.org/mingw/x86_64/ 
) and then calling "pacman -U  
mingw-w64-x86_64-binutils-2.35.1-3-any.pkg.tar.zst" on it. Emacs 
versions 27.2, 27.1, 26.3 and older would compile fine. But the master 
still won't. Instead of a segfault we get a more helpful Emacs crash. If 
we attach gdb to it, here's what we get:

#10 0x00007ff911ef0a9e in ntdll!KiUserExceptionDispatcher ()
    from /c/WINDOWS/SYSTEM32/ntdll.dll
#11 0x00007ff9103c43d7 in msvcrt!memmove () from 
/c/WINDOWS/System32/msvcrt.dll
#12 0x0000000400191e25 in insert_1_both (
     string=0x4506840 "(fn FILENAME)\377\377\377", nchars=13, nbytes=13,
     inherit=false, prepare=true, before_markers=false)
     at D:/Emacs/source/repo/src/insdel.c:915
#13 0x000000040024f689 in Fprin1_to_string (object=..., noescape=...)
     at D:/Emacs/source/repo/src/print.c:685
#14 0x000000040020be9a in styled_format (nargs=2, args=0xbf0720, 
message=false)
     at D:/Emacs/source/repo/src/editfns.c:3322
#15 0x000000040020b69f in Fformat (nargs=2, args=0xbf0720)
     at D:/Emacs/source/repo/src/editfns.c:3059
#16 0x000000040021b946 in eval_sub (form=...)
     at D:/Emacs/source/repo/src/eval.c:2363
#17 0x000000040021dbd0 in apply_lambda (fun=..., args=..., count=228)
     at D:/Emacs/source/repo/src/eval.c:3056

Again, memory related. Since we know that unexec works in emacs26 and 
emacs27 branches, I went for another row of bisecting and traced the 
offending commit to cddf85d256. Now this is interesting in that if 
unexec triggers a crash here, is there a way to get this to crash Emacs 
during the normal usage? Also, I have an old msys2 backup from 2017 that 
I've used for testing and I'm getting the same kind of exceptions with 
it, so I don't think we can write this master branch issue off on the 
build environment.