chain kill signals for cleanup functions
If a piece of code wanted to do some cleanup before exiting
(e.g., cleaning up a lockfile or a tempfile), our usual
strategy was to install a signal handler that did something
like this:
do_cleanup(); /* actual work */
signal(signo, SIG_DFL); /* restore previous behavior */
raise(signo); /* deliver signal, killing ourselves */
For a single handler, this works fine. However, if we want
to clean up two _different_ things, we run into a problem.
The most recently installed handler will run, but when it
removes itself as a handler, it doesn't put back the first
handler.
This patch introduces sigchain, a tiny library for handling
a stack of signal handlers. You sigchain_push each handler,
and use sigchain_pop to restore whoever was before you in
the stack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 09:02:35 +03:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='signals work as we expect'
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
cat >expect <<EOF
|
|
|
|
three
|
|
|
|
two
|
|
|
|
one
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'sigchain works' '
|
2018-03-24 10:44:58 +03:00
|
|
|
{ test-tool sigchain >actual; ret=$?; } &&
|
2016-06-30 11:16:18 +03:00
|
|
|
{
|
|
|
|
# Signal death by raise() on Windows acts like exit(3),
|
|
|
|
# regardless of the signal number. So we must allow that
|
|
|
|
# as well as the normal signal check.
|
|
|
|
test_match_signal 15 "$ret" ||
|
|
|
|
test "$ret" = 3
|
|
|
|
} &&
|
chain kill signals for cleanup functions
If a piece of code wanted to do some cleanup before exiting
(e.g., cleaning up a lockfile or a tempfile), our usual
strategy was to install a signal handler that did something
like this:
do_cleanup(); /* actual work */
signal(signo, SIG_DFL); /* restore previous behavior */
raise(signo); /* deliver signal, killing ourselves */
For a single handler, this works fine. However, if we want
to clean up two _different_ things, we run into a problem.
The most recently installed handler will run, but when it
removes itself as a handler, it doesn't put back the first
handler.
This patch introduces sigchain, a tiny library for handling
a stack of signal handlers. You sigchain_push each handler,
and use sigchain_pop to restore whoever was before you in
the stack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 09:02:35 +03:00
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2013-06-06 10:34:41 +04:00
|
|
|
test_expect_success !MINGW 'signals are propagated using shell convention' '
|
2013-06-01 21:24:41 +04:00
|
|
|
# we use exec here to avoid any sub-shell interpretation
|
|
|
|
# of the exit code
|
2018-03-24 10:44:58 +03:00
|
|
|
git config alias.sigterm "!exec test-tool sigchain" &&
|
2013-06-01 21:24:41 +04:00
|
|
|
test_expect_code 143 git sigterm
|
|
|
|
'
|
|
|
|
|
unblock and unignore SIGPIPE
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>
2014-09-18 20:57:09 +04:00
|
|
|
large_git () {
|
|
|
|
for i in $(test_seq 1 100)
|
|
|
|
do
|
|
|
|
git diff --cached --binary || return
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
test_expect_success 'create blob' '
|
2018-03-24 10:44:42 +03:00
|
|
|
test-tool genrandom foo 16384 >file &&
|
unblock and unignore SIGPIPE
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>
2014-09-18 20:57:09 +04:00
|
|
|
git add file
|
|
|
|
'
|
|
|
|
|
2014-09-22 22:24:34 +04:00
|
|
|
test_expect_success !MINGW 'a constipated git dies with SIGPIPE' '
|
2015-03-20 13:13:32 +03:00
|
|
|
OUT=$( ((large_git; echo $? 1>&3) | :) 3>&1 ) &&
|
2016-06-24 22:44:50 +03:00
|
|
|
test_match_signal 13 "$OUT"
|
unblock and unignore SIGPIPE
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>
2014-09-18 20:57:09 +04:00
|
|
|
'
|
|
|
|
|
2014-09-22 22:24:34 +04:00
|
|
|
test_expect_success !MINGW 'a constipated git dies with SIGPIPE even if parent ignores it' '
|
2015-03-20 13:13:32 +03:00
|
|
|
OUT=$( ((trap "" PIPE; large_git; echo $? 1>&3) | :) 3>&1 ) &&
|
2016-06-24 22:44:50 +03:00
|
|
|
test_match_signal 13 "$OUT"
|
unblock and unignore SIGPIPE
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>
2014-09-18 20:57:09 +04:00
|
|
|
'
|
|
|
|
|
chain kill signals for cleanup functions
If a piece of code wanted to do some cleanup before exiting
(e.g., cleaning up a lockfile or a tempfile), our usual
strategy was to install a signal handler that did something
like this:
do_cleanup(); /* actual work */
signal(signo, SIG_DFL); /* restore previous behavior */
raise(signo); /* deliver signal, killing ourselves */
For a single handler, this works fine. However, if we want
to clean up two _different_ things, we run into a problem.
The most recently installed handler will run, but when it
removes itself as a handler, it doesn't put back the first
handler.
This patch introduces sigchain, a tiny library for handling
a stack of signal handlers. You sigchain_push each handler,
and use sigchain_pop to restore whoever was before you in
the stack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 09:02:35 +03:00
|
|
|
test_done
|