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

[Cyril Arnould]

> Since you've already established sysdep.c alone is the culprit, I

> suggest to narrow this.  Create a separate file sysdep1.c, move to it

> the first portion of sysdep.c which includes everything before

> serial_open, and build Emacs with these two parts (you'd need to add

> sysdep1.o to base_obj in src/Makefile).  Once you have such an Emacs

> successfully built and reproduce the problem, rebuild by compiling

> sysdep1.c without -D_FORTIFY_SOURCE=2, and see if the problem goes

> away.  If it does, bisect sysdep1.c by moving parts of it back to

> sysdep.c, until you identify the smallest part of sysdep.c that needs

> to be compiled with -D_FORTIFY_SOURCE=2 to reproduce the problem.

> Then we will have to examine the effect of -D_FORTIFY_SOURCE=2 on that

> smallest part, and see if we can figure this out.

 

Thanks for the pointers! Following your advice, the first sysdep1.c with

code up until serial_open was working quite quickly. On a hunch, I've

singled out the emacs_intr_read function and got lucky: If I only put

the emacs_intr_read, emacs_read and emacs_read_quit functions into

sysdep1.c, the problems go away if sysdep1.o is compiled without

-D_FORTIFY_SOURCE=2.

 

Aside from those functions, sysdep1.c also contains all of the includes

of the original file; I figured it doesn't make much sense to narrow

those down further. I also had to add the MAX_RW_COUNT

definition. There's a patch attached; it can be tested as follows:

 

git clean -xdf

git checkout emacs-28.2

patch -p1 -i 0001-Single-out-emacs_read-as-culprit.patch

./autogen.sh

./configure

make CFLAGS='-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=2'

# The following command will result in an Emacs window where the

# asynchronous process doesn't terminate:

./src/emacs -Q --eval '(async-shell-command "dir")'

cd src

make sysdep1.o -W sysdep1.c

cd ..

make CFLAGS='-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=2'

# This time the process will terminate:

./src/emacs -Q --eval '(async-shell-command "dir")'

 

I've also attached another archive with the objects, dumps and

diff. This time it seems like the entire file is different. Is it

possible that GCC messes up with the read function that gets defined to

sys_read at the top?

 

> This is a lot of work, so kudos if you are motivated to go ahead and

> do it.  From my POV, the -D_FORTIFY_SOURCE=2 build is currently

> problematic on Windows and therefore not supported by the upstream

> project.  (IMNSHO, it is also wrong to use this in production builds

> of programs such as Emacs, but that's me, and I know others disagree.)

 

Fully understand, I really appreciate you helping despite the problem

being of low priority.

 

> My advice to MSYS2 folks at this time is to stop building Emacs that

> way until the problem is resolved.

 

The current release of Emacs on MSYS2 is indeed built without

-D_FORTIFY_SOURCE.

0001-Single-out-emacs_read-as-culprit.patch
Description: 0001-Single-out-emacs_read-as-culprit.patch

sysdep1-diff.tar.gz
Description: sysdep1-diff.tar.gz