> It's too bad the problem goes away under GDB, because we don't even

> know whether the crash is due to some fatal error in the Emacs code,

> or due to those extra-checking routines inserted into the code by the

> FORTIFY option.  IOW, it could be that the problem happens because the

> FORTIFY routines don't understand something Emacs does and consider it

> a bug worthy of aborting the program.

Oh, I think there might be some confusion with #63365, sorry if I

haven't been precise enough. This fortify bug does *not* go away under

GDB (unless I'm misunderstanding). I get the following output when

running the binary compiled with -D_FORTIFY_SOURCE:

$ gdb -q --args ./src/emacs -Q --eval '(async-shell-command "dir")'

Reading symbols from ./src/emacs...

(gdb) run

Starting program: I:\Git\emacs\src\emacs.exe -Q --eval "(async-shell-command \"dir\")"

[New Thread 15740.0x22e0]

[New Thread 15740.0x2b50]

[New Thread 15740.0x10cc]

[New Thread 15740.0x4f4]

[New Thread 15740.0x3eac]

[New Thread 15740.0x3c80]

The output then continues once I close the window:

[Thread 15740.0x4f4 exited with code 0]

[New Thread 15740.0x3b00]

[New Thread 15740.0x9ac]

[Thread 15740.0x3c80 exited with code 0]

[Thread 15740.0x10cc exited with code 0]

[Thread 15740.0x2b50 exited with code 0]

[Thread 15740.0x22e0 exited with code 0]

[Thread 15740.0x3b00 exited with code 0]

[Thread 15740.0x3eac exited with code 0]

[Thread 15740.0x9ac exited with code 0]

[Inferior 1 (process 15740) exited normally]

(gdb) quit

When running the binary where sysdep.o is compiled without

-D_FORTIFY_SOURCE, I get the following instead:

$ gdb -q --args ./src/emacs -Q --eval '(async-shell-command "dir")'

Reading symbols from ./src/emacs...

(gdb) run

Starting program: I:\Git\emacs\src\emacs.exe -Q --eval "(async-shell-command \"dir\")"

[New Thread 4364.0x36d4]

[New Thread 4364.0x3f38]

[New Thread 4364.0x3eec]

[New Thread 4364.0x924]

[New Thread 4364.0x38bc]

[New Thread 4364.0x2f8c]

[Thread 4364.0x2f8c exited with code 0]

And once I close the window:

[Thread 4364.0x924 exited with code 0]

[Thread 4364.0x36d4 exited with code 0]

[Thread 4364.0x3eec exited with code 0]

[Thread 4364.0x3f38 exited with code 0]

[Thread 4364.0x38bc exited with code 0]

[Inferior 1 (process 4364) exited normally]

(gdb) quit

The big difference being that in the latter case, the last thread exits

immediately (which I assume is the "dir" command), while with

-D_FORTIFY_SOURCE the thread only exits once I close the window. I can

perform further tests with GDB of course.

> Another interesting question is why the problems happen only in Emacs

> built with native compilation.  Do we use emacs_read or its callers in

> some special ways when they are called from comp.c or comp.el?

Again, there's some confusion with #63365. AFAICT, the fortify bug

occurs regardless of whether Emacs is built --with-native-compilation or

not. The third emacs-28.2 release on MSYS2 had the fortify bug and was

compiled --with-native-compilation. So far in *this* bug report I have

been using the default ./configure options, so native compilation should

be off in my objdumps.

In fact, I think the two bugs are not related at all. #63365 occurs

regardless of whether Emacs is built with or without -D_FORTIFY_SOURCE;

see the fourth and fifth release of Emacs on MSYS2.

Now, to make sure the two are not related, I've now repeated the process

with the following flags:

CFLAGS='-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=2 -fno-optimize-sibling-calls'

The fortify bug was still there, so it doesn't seem like

-foptimize-sibling-calls is the root cause for #63752. The objdump of

sysdep1.o is slightly different from the one compiled with

-foptimize-sibling-calls, I've attached it in case someone wants to take

a look but I don't think it's relevant.

> Maybe we should ask the MinGW64 folks who implemented the FORTIFY

> support for MinGW64 GCC to join this discussion and help us figure out

> which part(s) of this puzzle are relevant and why?  Cyril, can you

> reach out to them and ask them help us out here?

Sure, I've opened a support request:

https://sourceforge.net/p/mingw-w64/support-requests/193/