qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel.a@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Anthony Liguori <aliguori@amazon.com>,
	Markus Armbruster <armbru@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] qtest: fix crash if SIGABRT during qtest_init()
Date: Thu, 27 Mar 2014 15:34:31 +0200	[thread overview]
Message-ID: <1395927271.19041.10.camel@localhost.localdomain> (raw)
In-Reply-To: <533423D2.6030402@suse.de>

On Thu, 2014-03-27 at 14:12 +0100, Andreas Färber wrote:
> Am 27.03.2014 14:09, schrieb Markus Armbruster:
> > Reply after commit, sorry.
> > 
> > Stefan Hajnoczi <stefanha@redhat.com> writes:
> > 
> >> If an assertion fails during qtest_init() the SIGABRT handler is
> >> invoked.  This is the correct behavior since we need to kill the QEMU
> >> process to avoid leaking it when the test dies.
> >>
> >> The global_qtest pointer used by the SIGABRT handler is currently only
> >> assigned after qtest_init() returns.  This results in a segfault if an
> >> assertion failure occurs during qtest_init().
> >>
> >> Move global_qtest assignment inside qtest_init().  Not pretty but let's
> >> face it - the signal handler dependeds on global state.
> >>
> >> Reported-by: Marcel Apfelbaum <marcel.a@redhat.com>
> >> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> >> ---
> >>  tests/libqtest.c | 3 ++-
> >>  tests/libqtest.h | 4 +---
> >>  2 files changed, 3 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/tests/libqtest.c b/tests/libqtest.c
> >> index c9e78aa..f387662 100644
> >> --- a/tests/libqtest.c
> >> +++ b/tests/libqtest.c
> >> @@ -120,7 +120,7 @@ QTestState *qtest_init(const char *extra_args)
> >>      qemu_binary = getenv("QTEST_QEMU_BINARY");
> >>      g_assert(qemu_binary != NULL);
> >>  
> >> -    s = g_malloc(sizeof(*s));
> >> +    global_qtest = s = g_malloc(sizeof(*s));
> >>  
> >>      socket_path = g_strdup_printf("/tmp/qtest-%d.sock", getpid());
> >>      qmp_socket_path = g_strdup_printf("/tmp/qtest-%d.qmp", getpid());
> >> @@ -181,6 +181,7 @@ QTestState *qtest_init(const char *extra_args)
> >>  void qtest_quit(QTestState *s)
> >>  {
> >>      sigaction(SIGABRT, &s->sigact_old, NULL);
> >> +    global_qtest = NULL;
> >>  
> >>      kill_qemu(s);
> >>      close(s->fd);
> >> diff --git a/tests/libqtest.h b/tests/libqtest.h
> >> index 9deebdc..7e23a4e 100644
> >> --- a/tests/libqtest.h
> >> +++ b/tests/libqtest.h
> >> @@ -335,8 +335,7 @@ void qtest_add_func(const char *str, void (*fn));
> >>   */
> >>  static inline QTestState *qtest_start(const char *args)
> >>  {
> >> -    global_qtest = qtest_init(args);
> >> -    return global_qtest;
> >> +    return qtest_init(args);
> >>  }
> >>  
> >>  /**
> >> @@ -347,7 +346,6 @@ static inline QTestState *qtest_start(const char *args)
> >>  static inline void qtest_end(void)
> >>  {
> >>      qtest_quit(global_qtest);
> >> -    global_qtest = NULL;
> >>  }
> >>  
> >>  /**
> > 
> > Before this patch, the libqtest API could theoretically support multiple
> > simultaneous instances of QTestState.  This patch kills that option,
> > doesn't it?
> 
> Ouch, I thought I had looked out for that...
> 
> > 
> > If yes: fine with me, we don't need it anyway.
> 
> We do. Migration and ivshmem are examples that need two machines - might
> explain why my ivshmem-test was behaving unexpectedly.
> 
> Apart from reverting, what are our options?
The problem is in 'kill_qemu' function, which is called from
SIGABRT signal handler.  The later needs to know the QTestState
in order to kill the QEMU process.

Without this patch, kill_qemu will cause a segfault because of:
static void kill_qemu(QTestState *s)
{
    if (s->qemu_pid != -1) {
...
s can be NULL if there is an assert in qtest_init.

I suppose we can find a different approach, like keeping
the qemu_pid(s) in another statically defined struct.
 
Thanks,
Marcel

 
> 
> Regards,
> Andreas
> 
> >  But shouldn't we clean
> > up the API then?  It typically provides a function taking a QTestState
> > parameter, and a wrapper that passes global_qtest.  If global_qtest is
> > the only QTestState we can have, having the former function is
> > pointless.
> > 
> 
> 

  reply	other threads:[~2014-03-27 13:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-13  9:41 [Qemu-devel] [PATCH 0/2] qtest: crash fix and improved "make check" output Stefan Hajnoczi
2014-03-13  9:41 ` [Qemu-devel] [PATCH 1/2] tests: show the name of each executing qtest Stefan Hajnoczi
2014-03-13  9:41 ` [Qemu-devel] [PATCH 2/2] qtest: fix crash if SIGABRT during qtest_init() Stefan Hajnoczi
2014-03-13 11:07   ` Marcel Apfelbaum
2014-03-13 12:58     ` Stefan Hajnoczi
2014-03-13 20:10   ` Andreas Färber
2014-03-27 13:09   ` Markus Armbruster
2014-03-27 13:12     ` Andreas Färber
2014-03-27 13:34       ` Marcel Apfelbaum [this message]
2014-03-27 13:37         ` Stefan Hajnoczi
2014-03-27 14:02           ` Markus Armbruster
2014-03-27 14:03             ` Stefan Hajnoczi
2014-03-27 13:36       ` Stefan Hajnoczi
2014-03-13 11:07 ` [Qemu-devel] [PATCH 0/2] qtest: crash fix and improved "make check" output Marcel Apfelbaum

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=1395927271.19041.10.camel@localhost.localdomain \
    --to=marcel.a@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@amazon.com \
    --cc=armbru@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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).