qemu-devel
[Top][All Lists]
Advanced

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

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


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

On 17 February 2013 00:19, Peter Maydell <address@hidden> wrote:
> [why doesn't MacOS QEMU exit on ctrl-C?]
> 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.)

Found it! The culprit is the setjmp/longjmp in cpu-exec.c.
On Linux these don't save and restore the process signal mask
(you use sigsetjmp/siglongjmp for that). However on BSD setjmp
and longjmp do save and restore the process signal mask, so
when we do the longjmp in the CPU thread we end up setting the
mask for every thread to the restrictive mask used by the
CPU thread. Then SIGTERM and SIGINT are blocked for every
thread and have no effect on QEMU.

So, we can fix this MacOS issue by replacing all our current
setjmp() and longjmp() with sigsetjmp(buf, 0) and siglongjmp()
[which is the POSIX mandated way to say "definitely don't
change the signal mask", avoiding the undefined effect
on the signal mask that plain longjmp has.] (I guess that
might require some compat layer for win32 builds, which
is trivial enough.)

However, having thought about this I'm now a bit dubious about
the use of longjmp in cpu_resume_from_signal() -- this is
jumping out of a signal handler, so if we do nothing with
the signal mask surely we'll end up running the CPU thread
with that signal blocked when it was not before? I don't know
why this doesn't cause issues on Linux...

-- PMM



reply via email to

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