qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Doug Evans <1905651@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1905651] Re: Tests cannot call g_error
Date: Fri, 27 Nov 2020 05:11:04 -0000	[thread overview]
Message-ID: <160645386477.7529.14827063615441589298.malone@soybean.canonical.com> (raw)
In-Reply-To: 160635886967.28413.180075874214780604.malonedeb@chaenomeles.canonical.com

I don't know QEMU that well yet, but the following question arises: Why
can't QEMU be driven in a way that allows it to see that its controlling
parent has died -> causing QEMU to terminate as well. That way the test
doesn't need to care how it dies (e.g., we don't want a segfault to hang
testing; and nor do we, I think, want to install signal handlers for
every possible signal).

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1905651

Title:
  Tests cannot call g_error

Status in QEMU:
  New

Bug description:
  I stumbled on this writing a new test, using tests/qtest/e1000e-test.c
  as a template.

  g_error() causes SIGTRAP, not SIGABRT, and thus the abort handler doesn't get run.
  This in turn means qemu is not killed, which hangs the test because the tap-driver.pl script hangs waiting for more input.
  There are a few tests that call g_error().

  The SIGABRT handler explicitly kills qemu, e.g.:

  qos-test.c:
      qtest_add_abrt_handler(kill_qemu_hook_func, s);

  ref:
  https://git.qemu.org/?p=qemu.git;a=blob;f=tests/qtest/libqtest.c;h=e49f3a1e45f4cd96279241fdb2bbe231029ab922;hb=HEAD#l272

  But not unexpectedly there's no such handler for SIGTRAP.

  Apply this patch to trigger a repro:

  diff --git a/tests/qtest/e1000e-test.c b/tests/qtest/e1000e-test.c
  index fc226fdfeb..e83ace1b5c 100644
  --- a/tests/qtest/e1000e-test.c
  +++ b/tests/qtest/e1000e-test.c
  @@ -87,6 +87,9 @@ static void e1000e_send_verify(QE1000E *d, int *test_sockets, QGuestAllocator *a
       /* Wait for TX WB interrupt */
       e1000e_wait_isr(d, E1000E_TX0_MSG_ID);

  +    g_message("Test g_error hang ...");
  +    g_error("Pretend something timed out");
  +
       /* Check DD bit */
       g_assert_cmphex(le32_to_cpu(descr.upper.data) & dsta_dd, ==, dsta_dd);

  Then:

  configure
  make
  make check-qtest-i386

  check-qtest-i386 will take awhile. To repro faster:

  $ grep qtest-i386/qos-test Makefile.mtest
  .test.name.229 := qtest-i386/qos-test
  $ make run-test-229
  Running test qtest-i386/qos-test
  ** Message: 18:40:49.821: Test g_error hang ...

  ** (tests/qtest/qos-test:3820728): ERROR **: 18:40:49.821: Pretend something timed out
  ERROR qtest-i386/qos-test - Bail out! FATAL-ERROR: Pretend something timed out

  At this point things are hung because tap-driver.pl is still waiting
  for input because qemu is still running.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1905651/+subscriptions


  parent reply	other threads:[~2020-11-27  5:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26  2:47 [Bug 1905651] [NEW] Tests cannot call g_error Doug Evans
2020-11-26  4:00 ` [Bug 1905651] " Doug Evans
2020-11-27  5:11 ` Doug Evans [this message]
2021-05-10  4:43 ` Thomas Huth
2021-07-10  4:17 ` Launchpad Bug Tracker

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=160645386477.7529.14827063615441589298.malone@soybean.canonical.com \
    --to=1905651@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /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).