[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-3.0] tests/libqtest: Improve kill_qemu() ass
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH for-3.0] tests/libqtest: Improve kill_qemu() assert |
Date: |
Mon, 23 Jul 2018 13:59:09 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 07/23/2018 01:47 PM, Peter Maydell wrote:
In kill_qemu() we have an assert that checks that the QEMU process
didn't dump core:
assert(!WCOREDUMP(wstatus));
Unfortunately the WCOREDUMP macro here means the resulting message
is not very easy to comprehend on at least some systems:
ahci-test: tests/libqtest.c:113: kill_qemu: Assertion `!(((__extension__ (((union {
__typeof(wstatus) __in; int __i; }) { .__in = (wstatus) }).__i))) & 0x80)'
failed.
and it doesn't identify what signal the process took.
Instead of using a raw assert, print the information in an
easier to understand way:
/i386/ahci/sanity: tests/libqtest.c:119: kill_qemu() tried to terminate QEMU
process but it dumped core with signal 11 (Segmentation fault)
Aborted (core dumped)
(Of course, the really useful information would be why the QEMU
process dumped core in the first place, but we don't have that
by the time the test program has picked up the exit status.)
Last time we bike-shedded this, I suggested that we fix things to call
waitpid() in a loop, and that we just assert that exit status is 0:
https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg05610.html
In other words, why are we special-casing death-by-coredump, when ALL
non-zero exit status (whether or not a core dump was involved) is
contrary to the assumptions of the testsuite?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org