From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, peter.maydell@linaro.org,
thuth@redhat.com, mst@redhat.com, f4bug@amsat.org,
alex.bennee@linaro.org, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v3 for-3.0] tests/libqtest: Improve kill_qemu()
Date: Fri, 3 Aug 2018 12:11:03 -0500 [thread overview]
Message-ID: <0786b49a-6adf-0986-8970-135d27bc344a@redhat.com> (raw)
In-Reply-To: <874lgbih3r.fsf@dusky.pond.sub.org>
On 08/03/2018 10:51 AM, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> writes:
>
>> 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.
>>
>> - if (pid == s->qemu_pid && WIFSIGNALED(wstatus)) {
>> - assert(!WCOREDUMP(wstatus));
>> + assert(pid == s->qemu_pid);
>> + /*
>> + * We expect qemu to exit with status 0; anything else is
>> + * fishy and should be logged. Abort except when death by
>> + * signal is not accompanied by a coredump (as that's the only
>> + * time it was likely that the user is trying to kill the
>> + * testsuite early).
>> + */
>> + if (wstatus) {
>> + die = true;
>> + if (WIFEXITED(wstatus)) {
>> + fprintf(stderr, "%s:%d: kill_qemu() tried to terminate QEMU "
>> + "process but encountered exit status %d\n",
>> + __FILE__, __LINE__, WEXITSTATUS(wstatus));
>> + } else if (WIFSIGNALED(wstatus)) {
>> + int sig = WTERMSIG(wstatus);
>
> In review of v2, we found that WCOREDUMP() depends on the user's
> environment. I doubt we should use it this way.
>
> Why is suppressing the abort() when "the user is trying to kill the
> testsuite early" important?
>
Only because the old code was special-casing based on whether WCOREDUMP.
I'm not particularly attached to it, and am just fine submitting a v4
that just quits on ALL death-by-signal, rather than caring whether a
core dump was present.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
prev parent reply other threads:[~2018-08-03 17:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-30 22:08 [Qemu-devel] [PATCH v3 for-3.0] tests/libqtest: Improve kill_qemu() Eric Blake
2018-07-31 10:28 ` Richard Henderson
2018-08-01 7:59 ` Thomas Huth
2018-08-03 15:51 ` Markus Armbruster
2018-08-03 17:11 ` Eric Blake [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0786b49a-6adf-0986-8970-135d27bc344a@redhat.com \
--to=eblake@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=f4bug@amsat.org \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).