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

[Peter Maydell]

On Fri, 4 Jan 2019 at 11:01, Paolo Bonzini <address@hidden> wrote:
>
> On 04/01/19 11:06, Peter Maydell wrote:
> > On Fri, 4 Jan 2019 at 07:59, Paolo Bonzini <address@hidden> wrote:
> >>
> >> On 03/01/19 19:37, Peter Maydell wrote:
> >>> On Sat, 22 Dec 2018 at 08:41, Paolo Bonzini <address@hidden> wrote:
> >>> Interestingly, I have today run into "make: write error: stdout"
> >>> with the existing make check infrastructure. [...]
> >>> 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 ?
> >>
> >> I don't know... I tried running make check under "strace -e fcntl" and I
> >> didn't find any occurrences of fcntl(1, O_SETFL, ...|O_NONBLOCK).
> >> Perhaps you can add a check after every invocation of a test executable.
> >
> >> Are you going to apply the pull request since the bug is preexisting?
> >
> > The pull request takes the problem from "occasionally shows up
> > in by-hand running of make check in a while loop" to "reliably
> > causes my automated tests to fail every time". I can't apply
> > a pullreq that does that, so we need to find at least a workaround.
>
> The certain workaround is to clear O_NONBLOCK before invoking make,
> possibly by placing a wrapper in ~/bin:
>
>     import os
>     from fcntl import *
>     fcntl(1, F_SETFL, fcntl(1, F_GETFL) & ~os.O_NONBLOCK)

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.

(The semantics of O_NONBLOCK here seem to me to be completely
broken. But they are what they are...)

thanks
-- PMM