Subject: Re: [PATCH] run_processes_parallel(): fix order of sigpipe handling

From: Junio C Hamano <[email-masked]>
Date: Wed, 08 Apr 2026 13:54:26 -0700

Junio C Hamano <[email-masked]> writes:

>> Reported-by: Randall S. Becker <[email-masked]>
>> Signed-off-by: Jeff King <[email-masked]>
>
> Thanks, all of you, for addressing the issue so quickly.
>
> Applied.

We have a few places where we sigchain_push(SIGPIPE, SIG_IGN) then
run start_command().  One is in upload-pack.c where we spawn
"rev-list" for reachability check, and the other is in fetch-pack.c
where we spawn unpack-objects/index-pack.

Currently neither subprocess is marked with the clean-on-exit bit.
but if somebody is careless and flips the bit for these
subprocesses, start_command() will call mark_child_for_cleanup() and
causes sigchain_push_common() to set up cleanup_children_on_signal()
to be called, which would lead to a very similar bug.

I wonder if swapping the order of start_command() and sigchain_push()
in these two code paths have downsides, or is it making the code worse
just to futureproof it against a future that is unlikely to come?