bug#66186: "make lisp/eshell/esh-proc-tests" fails intermittently since 7e50861ca7ed3f620fe62ac6572f6e88b3600ece

[Jim Porter]

On 9/24/2023 2:35 PM, Jens Schmidt via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> * Broken Pipe with gdb Stack Trace
>
> [test]$ HOME=/nonexistent LANG=C EMACS_TEST_DIRECTORY=/home/jschmidt/work/emacs-master/test gdb -q 
> -batch -ex run -ex backtrace --args "../src/emacs" --module-assertions --no-init-file 
> --no-site-file --no-site-lisp -L ":."    -l ert  -l lisp/eshell/esh-proc-tests.el   
> --batch --eval '(ert-run-tests-batch-and-exit (quote (not (tag :unstable))))'
[snip]
>     passed   8/12  esh-proc-test/pipeline-connection-type/last2 (0.056252 sec)
> [Detaching after vfork from child process 7986]
> [Detaching after vfork from child process 7987]
>
> Thread 1 "emacs" received signal SIGPIPE, Broken pipe.
> 0x00007ffff57bffef in write () from /lib/x86_64-linux-gnu/libpthread.so.0
> #0  0x00007ffff57bffef in write () at /lib/x86_64-linux-gnu/libpthread.so.0
> #1  0x00005555556f2f08 in emacs_full_write (fd=19, buf=0x5555565918b8 "hi", 
> nbyte=2, interruptible=-1) at sysdep.c:2812
[snip]

Thanks. This looks like it's caused when Eshell runs a command something 
like this:

  echo hi | sh -c 'if [ -t 0 ]; then echo stdin; fi; ...'

(Note that the pipe above is handled entirely by Eshell, using 
'process-send-string' in this case.) I'm guessing that sometimes, the 
'sh' process has exited by the time Eshell calls '(process-send-string 
PROC "hi")'. Presumably, the commit you identified (which just changed 
some debug logging) altered the timings by just enough to trigger this 
race condition for you.

However, I don't understand why this would cause an abort though; 
normally, 'process-send-string' should just signal an Elisp error (which 
Eshell then catches and does the right thing with it). Maybe there's a 
bug somewhere in process.c where it's not correctly handling the (real) 
SIGPIPE signal and converting it to an Elisp signal?

I'm somewhat familiar with process.c, so I can take a look at this, but 
it'll probably be a week or two until I have time to really dig in. In 
the meantime, if anyone else wants to work on a fix, feel free.