cygwin 3.6.0: Signals may fail permanently if received after SIGSTOP

[Takashi Yano]

On Mon, 24 Feb 2025 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>