From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 08 Apr 2026 20:54:26 GMT
Subject: Re: [PATCH] run_processes_parallel(): fix order of sigpipe handling
Message-ID: <xmqqmrzdxjel.fsf@gitster.g>
In-Reply-To: <xmqqcy09z62e.fsf@gitster.g>

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

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