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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2026, 20:54 UTC
Message-ID: <xmqqmrzdxjel.fsf@gitster.g>
In-Reply-To: <xmqqcy09z62e.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 6 quoted lines

>> Reported-by: Randall S. Becker <rsbecker@nexbridge.com>
>> Signed-off-by: Jeff King <peff@peff.net>
>
> 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?