'socket_accept' waits for Qemu to init its unix socket. If Qemu encounters an error during command line parsing, it can exit before initializing the communication channel. It gets worse as the make check-qtest-* gets stuck without notifying which test exactly has problems, so debugging can be a challenge.
The solution has two parts: - Use a timeout for the socket. - Expose a qtest_state_valid that checks that the connections with Qemu are OK. Asserting qtest_state_valid in each test after qtest_init is a must, as we need to trace which test failed. As a nice side effect, even the nop tests will check at least that the device/option is still supported by Qemu. Note: I encountered this issue while working on 'Machine as QOM object'; because of my changes some tests tried to run qtest with a not supported machine. The result was 'make check' getting stuck with no clue why is happening. Marcel Apfelbaum (2): tests/libqtest: Fix possible deadlock in qtest initialization tests: check that qtest state is valid before starting the test tests/acpi-test.c | 4 +++- tests/blockdev-test.c | 4 +++- tests/boot-order-test.c | 4 +++- tests/e1000-test.c | 5 ++++- tests/eepro100-test.c | 1 + tests/endianness-test.c | 15 ++++++++++++--- tests/fdc-test.c | 5 ++++- tests/fw_cfg-test.c | 2 ++ tests/hd-geo-test.c | 20 ++++++++++++++++---- tests/i440fx-test.c | 10 ++++++++-- tests/ide-test.c | 5 ++++- tests/ipoctal232-test.c | 5 ++++- tests/libqtest.c | 26 +++++++++++++++++++++----- tests/libqtest.h | 8 ++++++++ tests/m48t59-test.c | 1 + tests/ne2000-test.c | 5 ++++- tests/pcnet-test.c | 5 ++++- tests/qdev-monitor-test.c | 4 +++- tests/qom-test.c | 10 ++++++++-- tests/rtc-test.c | 4 +++- tests/rtl8139-test.c | 5 ++++- tests/tmp105-test.c | 4 +++- tests/tpci200-test.c | 5 ++++- tests/virtio-net-test.c | 5 ++++- tests/vmxnet3-test.c | 5 ++++- 25 files changed, 135 insertions(+), 32 deletions(-) -- 1.8.3.1
