From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Adrian Ratiu <adrian.ratiu@collabora.com>,
rsbecker@nexbridge.com, git@vger.kernel.org
Subject: Re: [PATCH] run_processes_parallel(): fix order of sigpipe handling
Date: Wed, 08 Apr 2026 13:54:26 -0700 [thread overview]
Message-ID: <xmqqmrzdxjel.fsf@gitster.g> (raw)
In-Reply-To: <xmqqcy09z62e.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 08 Apr 2026 10:59:37 -0700")
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?
next prev parent reply other threads:[~2026-04-08 20:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 23:37 Help needed on 2.54.0-rc0 t5301.13 looping rsbecker
2026-04-08 5:20 ` Jeff King
2026-04-08 5:43 ` Jeff King
2026-04-08 11:53 ` Adrian Ratiu
2026-04-08 15:44 ` rsbecker
2026-04-08 15:52 ` rsbecker
2026-04-08 15:55 ` rsbecker
2026-04-08 16:53 ` Junio C Hamano
2026-04-08 16:58 ` rsbecker
2026-04-08 17:01 ` Adrian Ratiu
2026-04-08 17:30 ` [PATCH] t5401: test SIGPIPE with parallel hooks Jeff King
2026-04-08 15:50 ` Help needed on 2.54.0-rc0 t5301.13 looping Junio C Hamano
2026-04-08 16:26 ` Adrian Ratiu
2026-04-08 17:20 ` [PATCH] run_processes_parallel(): fix order of sigpipe handling Jeff King
2026-04-08 17:59 ` Junio C Hamano
2026-04-08 20:54 ` Junio C Hamano [this message]
2026-04-08 23:42 ` Jeff King
2026-04-09 13:40 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmrzdxjel.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=adrian.ratiu@collabora.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=rsbecker@nexbridge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.