[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
parallel autotest and signal handling failure (was: [GNU Autoconf 2.67]
parallel autotest and signal handling failure (was: [GNU Autoconf 2.67] testsuite: 199 246 failed)
Fri, 6 Aug 2010 21:35:08 +0200
Adding Scott in Cc:, he reported the same issue for Haiku:
* Bob Friesenhahn wrote on Wed, Aug 04, 2010 at 11:54:27PM CEST:
after running this test:
AT_CHECK([($CONFIG_SHELL ./micro-suite -d -3 5-; echo $? >status) | sed 5q],
trying (and failing) to solicit a SIGPIPE.
> 1: test number 1 ok
> 2: test number 2 ok
> /home/bfriesen/src/gnu/autoconf-2.67/tests/autotest.at:1493: grep '5.*ok'
> /home/bfriesen/src/gnu/autoconf-2.67/tests/autotest.at:1496: test ! -s status
> || grep 141 status || grep 269 status
> /home/bfriesen/src/gnu/autoconf-2.67/tests/autotest.at:1496: exit code was 1,
> expected 0
> resulting in this test failure:
> >micro-suite:1767: WARNING: caught signal TERM, bailing out
> 199. autotest.at:1391: 199. parallel autotest and signal handling
> (autotest.at:1391): FAILED (autotest.at:1496)
> This failure was included in the log I sent earlier. If it matters,
> 'make' on my system is GNU make 3.82.
I can reproduce the issue on Solaris, and IIRC it's been reported more
than once. I'm pretty sure this not a bug in Autoconf, but either in
the test or one of the tools involved:
Issue is that SIGPIPE is not seen by the left hand side of the pipe
despite the 'sed 5q'. I'm not sure if there are bugs involved or just
legitimate buffering, but if I add enough stdout output on the left-hand
side (slightly over 8K in the Solaris case) then I can reliably get a
Question for Eric is whether we would prefer adding another roughly 150
no-op (not 'sleep 1') test groups to this micro-suite and adjust the
rest of the test group accordingly, only to find out later that some
other system needs 16K, or just punt and remove these particular tests.