qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL v4 00/35] Misc patches for 2018-12-21


From: Peter Maydell
Subject: Re: [Qemu-devel] [PULL v4 00/35] Misc patches for 2018-12-21
Date: Thu, 3 Jan 2019 18:37:38 +0000

On Sat, 22 Dec 2018 at 08:41, Paolo Bonzini <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]