GNU bug report logs - #63752
28.2; GCC 13.1 breaks Emacs subprocess handling when built with -D_FORTIFY_SOURCE

Previous Next

Full log

View this message in rfc822 format

From: Cyril Arnould <cyril.arnould <at> outlook.com>
To: "eliz <at> gnu.org" <eliz <at> gnu.org>
Cc: "acorallo <at> gnu.org" <acorallo <at> gnu.org>, András Svraka <svraka.andras <at> gmail.com>, "63752 <at> debbugs.gnu.org" <63752 <at> debbugs.gnu.org>
Subject: bug#63752: 28.2; GCC 13.1 breaks Emacs subprocess handling when built with -D_FORTIFY_SOURCE
Date: Thu, 6 Jul 2023 19:28:40 +0000

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

[sysdep1-fortify-nosiblings.txt (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.