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: 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



reply via email to

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