qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] qemu on MacOS, failing to respond to ctrl-C


From: Peter Maydell
Subject: [Qemu-devel] qemu on MacOS, failing to respond to ctrl-C
Date: Sun, 17 Feb 2013 00:19:26 +0000

So I spent some time today investigating why ctrl-C doesn't quit
QEMU on MacOS. This is a specific instance of a general issue which
is that signals like SIGINT and SIGTERM don't end up in the os-posix.c
termination handler like they should.

(1) MacOS debug tools are deeply unhelpful here:
 (a) running under gdb() breaks sigwait()
 (b) dtrace probes for signal-send/signal-discard don't actually
     cover all the cases of a signal being sent, so neither trigger
     when you do a 'kill -TERM' of QEMU in this state

(2) Weird Stuff seems to be happening: it turns out the the reason
these signals don't work is that the main thread ends up with them
blocked, so with no thread with SIGTERM &c unblocked they just get
endlessly ignored.

I ended up adding logging printf()s all over the place which print the
thread ID and the current state of SIGTERM (blocked/unblocked).
The interesting bit is in this logging:

sigdebug: about to pthread_mutex_lock: TID 0x7fff7c1c1180: SIGTERM: unblocked
sigdebug: done pthread_mutex_lock: TID 0x7fff7c1c1180: SIGTERM: blocked

which is around the pthread_mutex_lock() call in qemu_mutex_lock().
We go in with SIGTERM unblocked, we come out with it locked...

dtruss says:

13176/0x6f8c35:  __pthread_sigmask(0x3, 0x0, 0x7FFF59F311AC)             = 0 0
13176/0x6f8c35:  write_nocancel(0x1, "sigdebug: about to
pthread_mutex_lock: TID 0x7fff7c1c1180: SIGTERM: unblocked\n\0", 0x4E)
         = 78 0
13176/0x6f8c53:  sigreturn(0x10BB07878, 0x1E, 0xAB5BB6621A84A222)
          = 0 Err#-2
13176/0x6f8c53:  sigprocmask(0x3, 0x10BB07DB0, 0x0)              = 0x0 0
13176/0x6f8c53:  sigreturn(0x0, 0x80000000, 0x0)                 = 0 0
13176/0x6f8c53:  sigprocmask(0x1, 0x0, 0x10BB07DD0)              = 0x0 0
13176/0x6f8c53:  sigaltstack(0x0, 0x10BB07DC0, 0x0)              = 0 0
13176/0x6f8c53:  psynch_cvwait(0x106714B78, 0x100000100, 0x0)            = 0 0
13176/0x6f8c35:  psynch_mutexwait(0x106714BA8, 0x543, 0x300)
  = 1283 0
13176/0x6f8c35:  __pthread_sigmask(0x3, 0x0, 0x7FFF59F311AC)             = 0 0
13176/0x6f8c35:  write_nocancel(0x1, "sigdebug: done
pthread_mutex_lock: TID 0x7fff7c1c1180: SIGTERM: blocked\n\0", 0x48)
             = 72 0

What seems to happen is that the other thread nips in and
does the sigreturn/sigprocmask/sigaltstack stuff, and
it's messing with the signal mask for the whole process.
(dtruss also tell me 0x6f8c53 is the TCG CPU thread.)

However I have no idea where the sigaltstack comes from,
since we're using the gthread coroutine backend, not the
sigaltstack one. Anybody got any ideas?

(I may look further at this tomorrow...)

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]