DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 525AO6jX4025962
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC6153858415
Subject: Re: cygwin 3.6.0: Signals may fail permanently if received after
 SIGSTOP
To: cygwin AT cygwin DOT com
References: <8c465025-4858-3113-fe2d-ce00dad21f8a AT t-online DOT de>
 <20250228212020 DOT 433a339f073060f65a0a736d AT nifty DOT ne DOT jp>
Message-ID: <de045db2-09b1-b2ab-d0d6-32f8c6906386@t-online.de>
Date: Wed, 5 Mar 2025 11:23:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101
 SeaMonkey/2.53.20
MIME-Version: 1.0
In-Reply-To: <20250228212020.433a339f073060f65a0a736d@nifty.ne.jp>
Content-Type: multipart/mixed; boundary="------------43BA9B67D7E9B80157F49CB0"
Precedence: list
From: Christian Franke via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Christian Franke <Christian DOT Franke AT t-online DOT de>
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

This is a multi-part message in MIME format.
--------------43BA9B67D7E9B80157F49CB0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Takashi Yano via Cygwin wrote:
> 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.

Testcase works as expected with 3.6.0-0.419.g3c1308ed890e.x86_64, thanks!


Unfortunately signals may be lost, a new testcase is attached:

$ uname -r
3.6.0-0.419.g3c1308ed890e.x86_64

$ gcc -o lostsig lostsig.c

$ ./lostsig
1157: fork()=1158
SIGALRM x 10
[ALRM]
[ALRM]
[ALRM]
SIGSTOP
[ALRM]
SIGTERM
SIGCONT
waitpid()...
[TERM]
1158: 4 SIGALRM received, exit(42)
waidpid()=1158, status=0x2a00

$ ./lostsig
1163: fork()=1164
SIGALRM x 10
SIGSTOP
SIGTERM
SIGCONT
waitpid()...
[ALRM]
[TERM]
...hangs...


A 'ps' is a second terminal then shows that the child process is still 
in S)topped state. 'kill -CONT ...' works to continue.

If the testcase is assigned to a single core with 'taskset 0x1 ...', it 
apparently always hangs.

-- 
Regards,
Christian


--------------43BA9B67D7E9B80157F49CB0
Content-Type: text/plain; charset=UTF-8;
 name="lostsig.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="lostsig.c"

I2luY2x1ZGUgPHNjaGVkLmg+DQojaW5jbHVkZSA8c2lnbmFsLmg+DQojaW5jbHVkZSA8c3Rk
aW8uaD4NCiNpbmNsdWRlIDxzdGRsaWIuaD4NCiNpbmNsdWRlIDx1bmlzdGQuaD4NCiNpbmNs
dWRlIDxzeXMvd2FpdC5oPg0KDQpzdGF0aWMgdm9sYXRpbGUgc2lnX2F0b21pY190IHNpZ2Nu
dCwgdGVybTsNCg0Kc3RhdGljIHZvaWQgc2lnaGFuZGxlcjEoaW50IHNpZykNCnsNCiAgKHZv
aWQpc2lnOw0KICArK3NpZ2NudDsNCiAgd3JpdGUoMSwgIltBTFJNXVxuIiwgNyk7DQp9DQoN
CnN0YXRpYyB2b2lkIHNpZ2hhbmRsZXIyKGludCBzaWcpDQp7DQogICh2b2lkKXNpZzsNCiAg
dGVybSA9IDE7DQogIHdyaXRlKDEsICJbVEVSTV1cbiIsIDcpOw0KfQ0KDQppbnQgbWFpbigp
DQp7DQogIHBpZF90IHBpZCA9IGZvcmsoKTsNCiAgaWYgKHBpZCA9PSAocGlkX3QpLTEpIHsN
CiAgICBwZXJyb3IoImZvcmsiKTsgcmV0dXJuIDE7DQogIH0NCg0KICBpZiAoIXBpZCkgew0K
ICAgIHNpZ25hbChTSUdBTFJNLCBzaWdoYW5kbGVyMSk7DQogICAgc2lnbmFsKFNJR1RFUk0s
IHNpZ2hhbmRsZXIyKTsNCg0KICAgIHdoaWxlICghdGVybSkNCiAgICAgIHNjaGVkX3lpZWxk
KCk7DQoNCiAgICBwcmludGYoIiVkOiAlZCBTSUdBTFJNIHJlY2VpdmVkLCBleGl0KDQyKVxu
IiwgKGludClnZXRwaWQoKSwgc2lnY250KTsNCiAgICBmZmx1c2goc3Rkb3V0KTsNCiAgICBf
ZXhpdCg0Mik7DQogIH0NCg0KICBwcmludGYoIiVkOiBmb3JrKCk9JWRcbiIsIChpbnQpZ2V0
cGlkKCksIChpbnQpcGlkKTsNCiAgc2xlZXAoMSk7DQoNCiAgY29uc3QgaW50IG4gPSAxMDsN
CiAgcHJpbnRmKCJTSUdBTFJNIHggJWRcbiIsIG4pOyBmZmx1c2goc3Rkb3V0KTsNCiAgZm9y
IChpbnQgaSA9IDA7IGkgPCBuOyBpKyspIHsNCiAgICBzY2hlZF95aWVsZCgpOw0KICAgIGlm
IChraWxsKHBpZCwgU0lHQUxSTSkpDQogICAgICBwZXJyb3IoIlNJR0FMUk0iKTsNCiAgfQ0K
DQogIHByaW50ZigiU0lHU1RPUFxuIik7IGZmbHVzaChzdGRvdXQpOw0KICBpZiAoa2lsbChw
aWQsIFNJR1NUT1ApKQ0KICAgIHBlcnJvcigiU0lHU1RPUCIpOw0KICBwcmludGYoIlNJR1RF
Uk1cbiIpOyBmZmx1c2goc3Rkb3V0KTsNCiAgaWYgKGtpbGwocGlkLCBTSUdURVJNKSkNCiAg
ICAgIHBlcnJvcigiU0lHVEVSTSIpOw0KICBwcmludGYoIlNJR0NPTlRcbiIpOyBmZmx1c2go
c3Rkb3V0KTsNCiAgaWYgKGtpbGwocGlkLCBTSUdDT05UKSkNCiAgICBwZXJyb3IoIlNJR0NP
TlQiKTsNCg0KICBwcmludGYoIndhaXRwaWQoKS4uLlxuIik7IGZmbHVzaChzdGRvdXQpOw0K
ICBpbnQgc3RhdHVzID0gLTE7DQogIGludCB3cCA9IHdhaXRwaWQocGlkLCAmc3RhdHVzLCAw
KTsNCiAgcHJpbnRmKCJ3YWlkcGlkKCk9JWQsIHN0YXR1cz0weCUwNHhcbiIsIHdwLCBzdGF0
dXMpOw0KICByZXR1cm4gMDsNCn0NCg==
--------------43BA9B67D7E9B80157F49CB0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

--------------43BA9B67D7E9B80157F49CB0--