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

[Peter Maydell]

On Fri, 4 Jan 2019 at 13:03, Peter Maydell <address@hidden> wrote:
>
> On Fri, 4 Jan 2019 at 07:59, Paolo Bonzini <address@hidden> wrote:
> > 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).
>
> I found this strace command worked to track down some possible
> culprits:
> strace -o /tmp/strace.log -e fcntl,execve,clone -e signal=none -f make
> -C build/x86 V=1 check
>
> Extracts from the logs:
>
> 29251 execve("tests/test-char", ["tests/test-char", "-q", "-p",
> "/char/stdio/subprocess", "--GTestSubprocess", "--GTestLogFD", "4"],
> [/* 66 vars */] <unfinished ...>

This one seems to be ok, because the call to g_test_trap_subprocess()
does not pass any flags arguments, which means the child gets
its stdin/stdout/stderr all set to /dev/null, and the change
to O_NONBLOCK is thus harmless.

> 30300 execve("tests/hexloader-test", ["tests/hexloader-test",
> "--quiet", "--keep-going", "-m
> =quick", "--GTestLogFD=6"], [/* 68 vars */]) = 0

This one on the other hand does seem like it might be an issue.
Removing the "-nographic" from the qtest_initf() command
causes it no longer to mess with the O_NONBLOCK state
of its stdout. I'm just doing a 'while loop' test run to
see if it fixes the problems I was seeing with that.

It seems a touch brittle if a harmless-looking command
line option to QEMU can break test runs, though -- is
there a way we can make this more robust, eg by having
the QEMU process i/o always redirected ?

thanks
-- PMM