On Fri, 4 Jan 2019 at 13:03, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Fri, 4 Jan 2019 at 07:59, Paolo Bonzini <pbonz...@redhat.com> 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