Re: parallel autotest and signal handling failure

[Eric Blake]

On 08/06/2010 01:35 PM, Ralf Wildenhues wrote:
> after running this test:
>   AT_CHECK([($CONFIG_SHELL ./micro-suite -d -3 5-; echo $? >status) | sed 5q],
> 

> 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
> failure.

I think the buffering is legitimate, and the bug is in the testsuite
assumptions and not in the tools - I see nothing in POSIX that requires
a non-interactive sh to be line-buffered (interactive sh should be
line-buffered, but do we dare trust $CONFIG_SHELL -i ./micro-suite to be
portable in an automated test?).  If we could force the left side to be
line-buffered, I think the patch would trigger more reliably.  But yeah,
the only way to be robust in the face of non-line-buffered tools is to
exceed PIPE_MAX bytes, so that the write transaction on the left side is
no longer atomic, such that the right side has to consume the first
buffer full and quit in time to force the continuation of the left side
to reliably see the SIGPIPE.

> 
> 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.

Would it help to use an alternative approach of front-loading the shell
command, so that the micro-suite output crosses the 8k boundary?
Something like:

lines=012345678901234567890123456789$as_nl # 31 bytes
lines=$lines$lines
lines=$lines$lines
lines=$lines$lines
lines=$lines$lines
lines=$lines$lines
lines=$lines$lines
lines=$lines$lines
lines=$lines$lines # now 7.75k long
AT_CHECK([(echo "$lines"; $CONFIG_SHELL ./micro-suite -d -3 5-; echo $?
>status) | sed '/test number 1/q'],
         [], [stdout], [stderr])

Then we don't have to pad out the micro-suite; but you are right that it
doesn't scale very well if PIPE_MAX is changed from 8k.

Or maybe do a shell loop where we double $lines until 'echo $lines | sed
5q' fails, and only then scale down $lines by enough bytes and throw
micro-suite into the mix, so that we are independent of PIPE_MAX (and on
Linux, where line-buffering appears to be default,

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature