[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: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] qemu on MacOS, failing to respond to ctrl-C |
Date: |
Mon, 18 Feb 2013 19:30:39 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130108 Thunderbird/10.0.12 |
On 02/17/13 01:59, Peter Maydell 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.
This is a bug in MacOSX. In POSIX there's no such thing as "whole
process signal mask". Signal *actions* are process-wide, signal *masks*
are always thread-specific.
Signals *themselves* can be generated & pending for the entire process
or just a specific thread. Delivery is always to a specific thread.
longjmp()
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/longjmp.html>
is indeed allowed to touch or not to touch the sigmask, but the sigmask
notion itself is bound to the thread. It has no business messing with
sigmasks of *other* threads.
However I agree that your fix / workaround for the problem is likely
appropriate.
Laszlo