On Sat, 22 Dec 2018 at 08:41, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 21/12/18 22:09, Peter Maydell wrote: > > I don't really understand what's going on here, or why > > it only happens with this one system (my main x86-64 > > Linux Ubuntu 16.04.5 box) and not the various others I'm > > running test builds on. But it does seem to be 100% > > reliable with any of these pullreqs with the new test > > driver in them :-( > > I'm afraid something in your setup is causing make's stdout to have > O_NONBLOCK set. Make doesn't use O_NONBLOCK at all, so it must be > something above it. I also checked Perl with strace and, at least here, > it doesn't set O_NONBLOCK.
Interestingly, I have today run into "make: write error: stdout" with the existing make check infrastructure. It seems to only happen if I run 'make check' in a loop like this: while make -C build/x86 -j8 V=1 check; do true; done Adding strace to this shows that although the first invocation of 'make' starts with stdout not O_NONBLOCK, something in that run results in stdout being set O_NONBLOCK, and then that persists into the second run of make, which then may fail as a result. (This is make 4.1, which will write output with fputs() unless a --sync-output option is used, and thus doesn't retry on EINTR.) When the 'while' loop finishes, something in the shell results in stdout being set back to blocking again. I presume that something in one of the tests we're running, likely QEMU itself, ends up setting stdout to non-blocking. This while rune *used* to be entirely reliable, so maybe something recent has changed ? thanks -- PMM
