From: Patrick Reynolds <patrick.reynolds@github.com>
To: git@vger.kernel.org
Cc: Patrick Reynolds <patrick.reynolds@github.com>,
Junio C Hamano <gitster@pobox.com>
Subject: [PATCH v2] unblock and unignore SIGPIPE
Date: Thu, 18 Sep 2014 11:57:09 -0500 [thread overview]
Message-ID: <1411059429-23868-1-git-send-email-patrick.reynolds@github.com> (raw)
Blocked and ignored signals -- but not caught signals -- are inherited
across exec. Some callers with sloppy signal-handling behavior can call
git with SIGPIPE blocked or ignored, even non-deterministically. When
SIGPIPE is blocked or ignored, several git commands can run indefinitely,
ignoring EPIPE returns from write() calls, even when the process that
called them has gone away. Our specific case involved a pipe of git
diff-tree output to a script that reads a limited amount of diff data.
In an ideal world, git would never be called with SIGPIPE blocked or
ignored. But in the real world, several real potential callers, including
Perl, Apache, and Unicorn, sometimes spawn subprocesses with SIGPIPE
ignored. It is easier and more productive to harden git against this
mistake than to clean it up in every potential parent process.
Signed-off-by: Patrick Reynolds <patrick.reynolds@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
1. Merged Junio's work from pu: moved restore_sigpipe_to_default into
git.c and restyled the new tests.
2. Moved the new tests into t0005. This meant switching back to `git
diff` as our data generator, as the sample repo in t0005 doesn't have any
files for `git ls-files` to output.
3. Squashed.
git.c | 22 ++++++++++++++++++++++
t/t0005-signals.sh | 22 ++++++++++++++++++++++
2 files changed, 44 insertions(+)
diff --git a/git.c b/git.c
index 210f1ae..0f03d56 100644
--- a/git.c
+++ b/git.c
@@ -593,6 +593,26 @@ static int run_argv(int *argcp, const char ***argv)
return done_alias;
}
+/*
+ * Many parts of Git have subprograms communicate via pipe, expect the
+ * upstream of the pipe to die with SIGPIPE and the downstream process
+ * even knows to check and handle EPIPE correctly. Some third-party
+ * programs that ignore or block SIGPIPE for their own reason forget
+ * to restore SIGPIPE handling to the default before spawning Git and
+ * break this carefully orchestrated machinery.
+ *
+ * Restore the way SIGPIPE is handled to default, which is what we
+ * expect.
+ */
+static void restore_sigpipe_to_default(void)
+{
+ sigset_t unblock;
+
+ sigemptyset(&unblock);
+ sigaddset(&unblock, SIGPIPE);
+ sigprocmask(SIG_UNBLOCK, &unblock, NULL);
+ signal(SIGPIPE, SIG_DFL);
+}
int main(int argc, char **av)
{
@@ -612,6 +632,8 @@ int main(int argc, char **av)
*/
sanitize_stdfds();
+ restore_sigpipe_to_default();
+
git_setup_gettext();
trace_command_performance(argv);
diff --git a/t/t0005-signals.sh b/t/t0005-signals.sh
index 981437b..638a355 100755
--- a/t/t0005-signals.sh
+++ b/t/t0005-signals.sh
@@ -27,4 +27,26 @@ test_expect_success !MINGW 'signals are propagated using shell convention' '
test_expect_code 143 git sigterm
'
+large_git () {
+ for i in $(test_seq 1 100)
+ do
+ git diff --cached --binary || return
+ done
+}
+
+test_expect_success 'create blob' '
+ test-genrandom foo 16384 >file &&
+ git add file
+'
+
+test_expect_success 'a constipated git dies with SIGPIPE' '
+ OUT=$( ((large_git; echo $? 1>&3) | :) 3>&1 )
+ test "$OUT" -eq 141
+'
+
+test_expect_success 'a constipated git dies with SIGPIPE even if parent ignores it' '
+ OUT=$( ((trap "" PIPE; large_git; echo $? 1>&3) | :) 3>&1 )
+ test "$OUT" -eq 141
+'
+
test_done
--
2.0.1
next reply other threads:[~2014-09-18 16:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 16:57 Patrick Reynolds [this message]
2014-09-18 17:35 ` [PATCH v2] unblock and unignore SIGPIPE Junio C Hamano
2014-09-18 18:39 ` James Nylen
2014-09-20 8:42 ` Johannes Sixt
2014-09-22 17:30 ` Junio C Hamano
2014-09-22 18:24 ` [PATCH] mingw.h: add dummy functions for sigset_t operations Johannes Sixt
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=1411059429-23868-1-git-send-email-patrick.reynolds@github.com \
--to=patrick.reynolds@github.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).