aboutsummaryrefslogtreecommitdiff
path: root/t/t0005-signals.sh
Commit message (Collapse)AuthorAge
* t0005: use test_match_signal as appropriateJeff King2016-07-06
| | | | | | | | | | The first test already uses this more portable construct (that was where it was factored from initially), but the later tests do a raw comparison against 141 to look for SIGPIPE, which can fail on some shells and platforms. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tests: factor portable signal check out of t0005Jeff King2016-07-06
| | | | | | | | | | | | | | | | | | | | | | | | In POSIX shells, a program which exits due to a signal generally has an exit code of 128 plus the signal number. However, ksh uses 256 plus the signal number. We've accounted for that in t0005, but not in other tests. Let's pull out the logic so we can use it elsewhere. It would be nice for debugging if this additionally printed errors to stderr, like our other test_* helpers. But we're going to need to use it in other places besides the innards of a test_expect block. So let's leave it as generic as possible. Note that we also leave the magic "3" for Windows out of the generic helper. This is an artifact of the way we use raise() to kill ourselves in test-sigchain.c, and will not necessarily apply to all programs. So it's better to keep it out of the helper, to reduce the chance of confusing it with a real call to exit(3). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t0005: fix broken &&-chainsJeff King2015-03-20
| | | | | | | | | The ":" noop command always returns true, so it is fine to include these lines in an &&-chain (and it appeases --chain-lint). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t: wrap complicated expect_code users in a blockJeff King2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If we are expecting a command to produce a particular exit code, we can use test_expect_code. However, some cases are more complicated, and want to accept one of a range of exit codes. For these, we end up with something like: cmd; case "$?" in ... That unfortunately breaks the &&-chain and fools --chain-lint. Since these special cases are so few, we can wrap them in a block, like this: { cmd; ret=$?; } && case "$ret" in ... This accomplishes the same thing, and retains the &&-chain (the exit status fed to the && is that of the assignment, which should always be true). It's technically longer, but it is probably a good thing for unusual code like this to stand out. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mingw.h: add dummy functions for sigset_t operationsJohannes Sixt2014-09-22
| | | | | | | | | | | | | Windows does not have POSIX-like signals, and so we ignore all operations on the non-existent signal mask machinery. Do not turn sigemptyset into a function, but leave it a macro that erases the code in the argument because it is used to set sa_mask of a struct sigaction, but our dummy in mingw.h does not have that member. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* unblock and unignore SIGPIPEPatrick Reynolds2014-09-18
| | | | | | | | | | | | | | | | | | | 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>
* t0005: skip signal death exit code test on WindowsJohannes Sixt2013-06-06
| | | | | | | | | | | | | | | | | | | The test case depends on that test-sigchain can commit suicide by a call to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect as death through a signal. There are no POSIX signals on Windows, and a sufficiently close emulation is not available in the Microsoft C runtime (and probably not even possible). The particular deficiency is that when a signal is raise()d whose SIG_DFL action will cause process death (SIGTERM in this case), the implementation of raise() in msvcrt just calls exit(3). We could check for exit code 3 in addition to 143, but that would miss the point of the test entirely. Hence, just skip it on Windows. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t0005: test git exit code from signal deathJeff King2013-06-02
| | | | | | | | | | When a sub-process dies with a signal, we convert the exit code to the shell convention of 128+sig. Callers of git may be relying on this behavior, so let's make sure it does not break. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t0005: work around strange $? in ksh when program terminated by a signalJohannes Sixt2010-07-09
| | | | | | | | | ksh93 is known to report $? of programs that terminated by a signal as 256 + signal number instead of 128 + signal number like other POSIX compliant shells (ksh's behavior is still POSIX compliant in this regard). Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t0005: use SIGTERM for sigchain testJeff King2009-01-30
| | | | | | | | | | | | | | | | | | | The signal tests consists of checking that each of our handlers is executed, and that the test program was killed by the final signal. We arbitrarily used SIGINT as the kill signal. However, some platforms (notably Solaris) will default SIGINT to SIG_IGN if there is no controlling terminal. In that case, we don't end up killing the program with the final signal and the test fails. This is a problem since the test script should not depend on outside factors; let's use SIGTERM instead, which should behave consistently. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* chain kill signals for cleanup functionsJeff King2009-01-21
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>