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

[Blue Swirl]

On Sun, Feb 17, 2013 at 12:59 AM, Peter Maydell
<address@hidden> wrote:
> 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...

Long time ago, QEMU did not use any threads. They were introduced by
CONFIG_IOTHREAD which then took over.

>
> -- PMM