Ok, I think I've got a clue. It's probably the only one I'll have this year,
but, hey, it's a clue.
Many thanks for the help testing this. Here's a 0.32 that might
address this business:
http://slaysys.com/src/IPC-Run-0.32.tar.gz
I think it's just a typical race condition between the child's outputting to
a pipe and the parent's picking up the results. The child is outputting
to STDOUT, then to STDERR. The parent is reading until STDOUT has the
expected value, then continueing, no matter whether STDERR has finished
filling. This is a bug in pty/t.
When in debug mode, there's an extra pipe opened, which the parent reads
first, so that it emits debug info already emitted by the child before
trying anything else:
> harness: 01234567---- creating debug pipe
> harness: 0123456789-- pipe() = ( 8, 9 )
> harness: 0123456789-- kid 0[]'s 9 is my 8
...
> harness: 0123456789-- fork() = 7595
...
> harness: 0123-56-8--- ** pumping
> harness: 0123-56-8--- selecting ---r-wr-r--- with timeout=forever
> harness: 0123-56-8--- selected ---r-wr-r---
> harness[7593]: 0123456789-- Cleaning up parent's ptty '0'
> harness[7593]: 012-4567890- closing stdin, out, err
That extra effort is probably taking long enough or causing enough
I/O waits that the kernel or the child process has enough time to fill
up the STDERR pipe/pty (depending on the test run).
I'm not sure why being on ppc-linux should affect this, but there's
a bunch of possibilities, from a differing number of instructions per
time slice to different order of dealing with I/O pipes due to some
endian assumption or compiler optimization in the pipe or pty drivers
or the kernel. It's likely it would have shown up on other platforms.
Again, many thanks for the testing, and let's hope that this nailed it.
- Barrie
