cygwin 3.6.0: Signals may fail permanently if received after SIGSTOP

Takashi Yano takashi.yano@nifty.ne.jp
Fri Feb 28 12:20:20 GMT 2025


On 2025年2月24日 11:29:59 +0100
Christian Franke wrote:
> Found with 'stress-ng --cpu-sched 1':
>> Testcase (attached):
>> $ uname -r
> 3.6.0-0.387.g8cebbb2b42bf.x86_64
>> $ gcc -o timersig timersig.c
>> $ ./timersig
> 638: fork()=639
> !!!!!!!!!!!!!...!!!!!!!!!!!!!SIGSTOP: Permission denied
>     0 [itimer] timersig 639 sig_send: error sending signal 14, pid 639, 
> pipe handle 0x14C, nb 0, packsize 192, Win32 error 0
> SIGKILL: Permission denied
>> $ kill 639
> -bash: kill: (639) - Permission denied
>> $ kill -9 639
> -bash: kill: (639) - Permission denied
>> $ /bin/kill --force 639
>> $ /bin/kill --force 639
> kill: 639: No such process
>>> A similar problem, but without the "error sending signal" message, 
> occurs if the timer is not used but the parent process issues SIGSTOP 
> SIGALRM SIGCONT ... sequences.

Thanks for the report, especially for the test case. I was able to
easily reproduce the issue. However, I haven't found the cause until
today. I spent 3 days investigating and discovered three bugs that
prevent the test case from behaving as expected.
I'll submit the patch seriese shotly.
-- 
Takashi Yano <takashi.yano@nifty.ne.jp>


More information about the Cygwin mailing list

AltStyle によって変換されたページ (->オリジナル) /