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