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

[Cyril Arnould <cyril.arnould@outlook.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4255 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 8367 bytes --]

[-- Attachment #2: sysdep1-fortify-nosiblings.txt --]
[-- Type: text/plain, Size: 4368 bytes --]


src/sysdep1.o:     file format pe-x86-64


Disassembly of section .text:

0000000000000000 <emacs_intr_read>:
   if INTERRUPTIBLE, and then retry the read unless quitting.
   Return the number of bytes read, which might be less than NBYTE.
   On error, set errno to a value other than EINTR, and return -1.  */
static ptrdiff_t
emacs_intr_read (int fd, void *buf, ptrdiff_t nbyte, bool interruptible)
{
   0:	41 56                	push   %r14
   2:	41 55                	push   %r13
   4:	41 54                	push   %r12
   6:	55                   	push   %rbp
   7:	57                   	push   %rdi
   8:	56                   	push   %rsi
   9:	53                   	push   %rbx
   a:	48 83 ec 20          	sub    $0x20,%rsp
   e:	4c 8b 2d 00 00 00 00 	mov    0x0(%rip),%r13        # 15 <emacs_intr_read+0x15>
    {
      if (interruptible)
	maybe_quit ();
      result = read (fd, buf, nbyte);
    }
  while (result < 0 && errno == EINTR);
  15:	4c 8b 35 00 00 00 00 	mov    0x0(%rip),%r14        # 1c <emacs_intr_read+0x1c>
{
  1c:	41 89 cc             	mov    %ecx,%r12d
  1f:	48 89 d5             	mov    %rdx,%rbp
  22:	44 89 cf             	mov    %r9d,%edi
      result = read (fd, buf, nbyte);
  25:	44 89 c6             	mov    %r8d,%esi
  28:	eb 22                	jmp    4c <emacs_intr_read+0x4c>
  2a:	66 0f 1f 44 00 00    	nopw   0x0(%rax,%rax,1)

__mingw_bos_extern_ovr
int _read(int __fh, void * __dst, unsigned int __n)
{
  __mingw_bos_ptr_chk_warn(__dst, __n, 0);
  return __mingw_call__read(__fh, __dst, __n);
  30:	41 89 f0             	mov    %esi,%r8d
  33:	48 89 ea             	mov    %rbp,%rdx
  36:	44 89 e1             	mov    %r12d,%ecx
  39:	41 ff d5             	call   *%r13
  3c:	48 63 d8             	movslq %eax,%rbx
  while (result < 0 && errno == EINTR);
  3f:	48 85 db             	test   %rbx,%rbx
  42:	79 1c                	jns    60 <emacs_intr_read+0x60>
  44:	41 ff d6             	call   *%r14
  47:	83 38 04             	cmpl   $0x4,(%rax)
  4a:	75 14                	jne    60 <emacs_intr_read+0x60>
      if (interruptible)
  4c:	40 84 ff             	test   %dil,%dil
  4f:	74 df                	je     30 <emacs_intr_read+0x30>
	maybe_quit ();
  51:	e8 00 00 00 00       	call   56 <emacs_intr_read+0x56>
  56:	eb d8                	jmp    30 <emacs_intr_read+0x30>
  58:	0f 1f 84 00 00 00 00 	nopl   0x0(%rax,%rax,1)
  5f:	00 

  return result;
}
  60:	48 89 d8             	mov    %rbx,%rax
  63:	48 83 c4 20          	add    $0x20,%rsp
  67:	5b                   	pop    %rbx
  68:	5e                   	pop    %rsi
  69:	5f                   	pop    %rdi
  6a:	5d                   	pop    %rbp
  6b:	41 5c                	pop    %r12
  6d:	41 5d                	pop    %r13
  6f:	41 5e                	pop    %r14
  71:	c3                   	ret
  72:	66 66 2e 0f 1f 84 00 	data16 cs nopw 0x0(%rax,%rax,1)
  79:	00 00 00 00 
  7d:	0f 1f 00             	nopl   (%rax)

0000000000000080 <emacs_read>:

ptrdiff_t
emacs_read (int fd, void *buf, ptrdiff_t nbyte)
{
  80:	48 83 ec 28          	sub    $0x28,%rsp
  return emacs_intr_read (fd, buf, nbyte, false);
  84:	45 31 c9             	xor    %r9d,%r9d
  87:	e8 74 ff ff ff       	call   0 <emacs_intr_read>
}
  8c:	48 83 c4 28          	add    $0x28,%rsp
  90:	c3                   	ret
  91:	66 66 2e 0f 1f 84 00 	data16 cs nopw 0x0(%rax,%rax,1)
  98:	00 00 00 00 
  9c:	0f 1f 40 00          	nopl   0x0(%rax)

00000000000000a0 <emacs_read_quit>:

/* Like emacs_read, but also process quits and pending signals.  */
ptrdiff_t
emacs_read_quit (int fd, void *buf, ptrdiff_t nbyte)
{
  a0:	48 83 ec 28          	sub    $0x28,%rsp
  return emacs_intr_read (fd, buf, nbyte, true);
  a4:	41 b9 01 00 00 00    	mov    $0x1,%r9d
  aa:	e8 51 ff ff ff       	call   0 <emacs_intr_read>
}
  af:	48 83 c4 28          	add    $0x28,%rsp
  b3:	c3                   	ret
  b4:	90                   	nop
  b5:	90                   	nop
  b6:	90                   	nop
  b7:	90                   	nop
  b8:	90                   	nop
  b9:	90                   	nop
  ba:	90                   	nop
  bb:	90                   	nop
  bc:	90                   	nop
  bd:	90                   	nop
  be:	90                   	nop
  bf:	90                   	nop