]> git.ipfire.org Git - thirdparty/git.git/commit
t5512.40 sometimes dies by SIGPIPE
authorJunio C Hamano <gitster@pobox.com>
Fri, 13 Sep 2024 19:26:41 +0000 (12:26 -0700)
committerJunio C Hamano <gitster@pobox.com>
Fri, 13 Sep 2024 19:45:55 +0000 (12:45 -0700)
commite1e0d305c417448753162129f694afa9f183c03e
tree99e3c08a9fb225101f04a5246427a74db85aa8bf
parent760348212b16379d2646751c2cd18a028cbdd02d
t5512.40 sometimes dies by SIGPIPE

The last test in t5512 we recently added seems to be flaky.
Running

    $ make && cd t && sh ./t5512-ls-remote.sh --stress

shows that "git ls-remote foo::bar" exited with status 141, which
means we got a SIGPIPE.  This test piece was introduced by 9e89dcb6
(builtin/ls-remote: fall back to SHA1 outside of a repo, 2024-08-02)
and is pretty much independent from all other tests in the script
(it can even run standalone with everything before it removed).

The transport-helper.c:get_helper() function tries to write to the
helper.  As we can see the helper script is very short and can exit
even before it reads anything, when get_helper() tries to give the
first command, "capabilities", the helper may already be gone.

A trivial fix, presented here, is to make sure that the helper reads
the first command it is given, as what it writes later is a response
to that command.

I however would wonder if the interactions with the helper initiated
by get_helper() should be done on a non-blocking I/O (we do check
the return value from our write(2) system calls, do we?).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5512-ls-remote.sh