I ran "make check" on gzip after today's changes on my x86-64 host (recently upgraded to Fedora 15), and one test fails if I invoke "make check" from inside an Emacs shell window. (It works if I invoke "make check" from an ordinary terminal window.) That is, if I run Emacs, and type "M-x shell RET", and inside the resulting shell I type "make check", then the zgrep-signal test fails.
This appears to be an issue where a 'write' fails with errno == EPIPE even though the SIGPIPE signal is not being caught or ignored. I do not observe this problem on a different x86-64 host that is running RHEL 5.7. I expect this is the same problem that you found back in 2007 with dbus <http://lists.gnu.org/archive/html/bug-coreutils/2007-11/msg00154.html>. What ever became of that? For now, I've installed the following patch, so that others who run into this problem don't incorrectly think that it's gzip's fault. While I was at it, I made sure PIPE was SIG_DFL, removing an unwarranted assumption in the current test. * tests/zgrep-signal: Test for Fedora 15 signal bug. Also, don't assume that SIGPIPE is SIG_DFL on entry. diff --git a/tests/zgrep-signal b/tests/zgrep-signal index fc09a9e..3c5b696 100644 --- a/tests/zgrep-signal +++ b/tests/zgrep-signal @@ -22,6 +22,14 @@ echo a | gzip -c > f.gz || framework_failure_ +if (trap - PIPE) >/dev/null 2>&1; then + trap - PIPE +else + trap 13 +fi +st=$(exec 3>&1; (cat f.gz f.gz; echo $? >&3) | :) +test "$st" = 141 || framework_failure_ 'signal handling busted on this host' + fail=0 st=$(exec 3>&1; (zgrep a f.gz f.gz; echo $? >&3) | :) || framework_failure_
