Signal delivered while blocked

Marco Atzeri marco.atzeri@gmail.com
Tue Dec 28 02:46:06 GMT 2021


On 28.12.2021 00:14, David McFarland wrote:
> 
>> Hi Guys,
>>
>> Some time ago (2017) a Postgres developer reported a signal issue
>> not present in older version (2013)
>>
>> https://sourceware.org/pipermail/cygwin/2017-August/234001.html
>>
>> For what I can see the issue is still present.
>>
>>
>> Ideas for debugging ?
> 
> I had a look at your program. What seems to be happening is that he
> signal thread receives the signal, and uses find_tls to find a thread to
> handle it. If this is after a call to sigpermit(), then the mask will
> be zero and it will commit to sending the signal to the main thread of
> the test program.
> 
> This is done without any lock, so the main thread can now handle an
> existing signal, call sigforbid() then usleep().
> 
> At this point the signal thread can resume, queuing up the next signal,
> and the main thread will pick it up when usleep calls
> sig_dispatch_pending, even though the main thread signal mask now
> disallows it.
> 
> The old thread ended with a discussion about whether this is even valid
> se of sigprocmask(), which didn't seem to be resolved. Anyone have any
> thoughts on that?

Thanks David,

I am not an expert in signal, but it seems the program is working as 
expected on Linux and other platforms and only cygwin is presenting it.
I have not anymore a Linux box so I can not check.

The test case is not mine, it is coming from Noah Misch,
https://www.postgresql.org/message-id/20170811021007.GB3623941%40rfd.leadboat.com
that also reported in 2017 on the Cygwin mailing list


and the discussion was recently revived on the Postgres dev list
https://www.postgresql.org/message-id/20210622064212.GA1367859@rfd.leadboat.com

Regards
Marco


More information about the Cygwin-developers mailing list