Hi On Thu, May 24, 2018 at 5:00 PM, Michael S. Tsirkin <[email protected]> wrote: > On Thu, May 24, 2018 at 04:45:31PM +0200, Thomas Huth wrote: >> On 24.05.2018 16:30, Michael S. Tsirkin wrote: >> > Right now tests report OK status if QEMU crashes during cleanup. >> > Let's catch that case and fail the test. >> > >> > Signed-off-by: Michael S. Tsirkin <[email protected]> >> > --- >> > tests/libqtest.c | 9 ++++++++- >> > 1 file changed, 8 insertions(+), 1 deletion(-) >> > >> > diff --git a/tests/libqtest.c b/tests/libqtest.c >> > index 43fb97e..f869854 100644 >> > --- a/tests/libqtest.c >> > +++ b/tests/libqtest.c >> > @@ -103,8 +103,15 @@ static int socket_accept(int sock) >> > static void kill_qemu(QTestState *s) >> > { >> > if (s->qemu_pid != -1) { >> > + int wstatus = 0; >> > + pid_t pid; >> > + >> > kill(s->qemu_pid, SIGTERM); >> > - waitpid(s->qemu_pid, NULL, 0); >> > + pid = waitpid(s->qemu_pid, &wstatus, 0); >> > + >> > + if (pid == s->qemu_pid && WIFSIGNALED(wstatus)) { >> > + assert(!WCOREDUMP(wstatus)); >> > + } >> > } >> > } >> >> That's basically a good idea ... but I've already seen yet another issue >> in the past already: QEMU sometimes simply hangs in an endless loop >> during clean up and never terminates. I think we should detect that >> situation, too. So instead of killing QEMU at the end of the testing, I >> think we should >> rather try to terminate it with the QMP "quit" command. If QEMU does not >> terminate with an exit code of 0, then the test should be flagged a >> failed (and only if QEMU did not terminate at all, it should be killed >> with SIGKILL). >> >> Thomas > > Fine but can we agree to do this as a patch on top? And do you have > the time to implement this? > > I'm seeing patches that cause crash on cleanup, it's not a theoretical > problem for me, so I'd like this one to go in first.
What is the difference between sending "quit" and SIGTERM (qemu has code to handle it in termsig_handler()). Is this documented somewhere? -- Marc-André Lureau
