On 04/01/19 12:31, Peter Maydell wrote: > I'll give this a go, but I think this will not necessarily be > sufficient if some program invoked by make sets the O_NONBLOCK flag, > and then make later in the same run tries to output and gets EINTR. > Perhaps it would be better to put it in the test harness that > invokes test binaries, so as to clear the flag as soon > as possible? It could also then in theory print a warning > if a test case had put stdin/stdout into non-blocking mode.
Aha, you gave me the clue I needed. :) gtester redirected stdin/out/err to /dev/null. In the new harness, stdout is piped into tap-driver.pl, but everything else is left in place. Leaving stderr should be safe, while stdin is the most likely culprit. Adding </dev/null to the test invocation should fix it; I'll send a new pull request either today or next Monday. > (The semantics of O_NONBLOCK here seem to me to be completely > broken. But they are what they are...) Yes, and F_SETFL is not the only "interesting" fcntl in this respect; fortunately QEMU is not using F_SETOWN anymore! Paolo