DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; q=dns; s=default; b=
	Wx8RwKxRcLHBpwpCmUgL4sZKHotnUsDqAL3l/KGWvgIKFa9I9yw0s0SqLgTQQy8F
	lK6GKY7RsGHs0VAy/s6BmCgraZyiZg1Y/VMCCIQQ63pt+ikCLZE9yYbQ+jfIpEH6
	nBXm6rTCky4OVvNYf0JesZHrz70rzeQrzw1NMr0hgsw=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <51BDB979.3040508@cornell.edu>
Date: Sun, 16 Jun 2013 09:11:21 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Angelo Graziosi <angelo DOT graziosi AT alice DOT it>
CC: cygwin AT cygwin DOT com, 14569 AT debbugs DOT gnu DOT org, Paul Eggert <eggert AT cs DOT ucla DOT edu>
Subject: Re: bug#14569: 24.3.50; bootstrap fails on Cygwin
References: <51BC720D DOT 7080504 AT alice DOT it>
In-Reply-To: <51BC720D.7080504@alice.it>
Content-Type: multipart/mixed; boundary="------------060004040501040900040907"

--------------060004040501040900040907
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

[Adding the bug address back to the CC so that this gets archived.]

On 6/15/2013 9:54 AM, Angelo Graziosi wrote:
> Christopher Faylor wrote
>>> On 06/14/2013 11:03 AM, Christopher Faylor wrote:
>>>> You pointed to an archived mail messages which implies that was fixed
>>>> more than a year ago.  What makes you think it is still a problem?
>>>
>>> The message I pointed to
>>> <http://cygwin.com/ml/cygwin/2012-05/msg00472.html> says this:
>>>
>>>> Testcase signal/kill: Signals may or may not reach the correct thread
>>>> with 1.7.12-1 and newer.
>>>
>>> Confirmed.  I think the reason is that we only have a single event to
>>> signal that a POSIX signal arrived instead of a per-thread event, but
>>> I'm not sure.  This is cgf's domain so I leave it at that for now.
>>>
>>> I interpreted this to mean "the existence of the bug is confirmed,
>>> here's why the bug occurs, and I'll let cgf deal with it".  I didn't
>>> see any followup message where cgf (is that you?) dealt with it.  My
>>> apologies if I misinterpreted the email.
>>
>> Oops.  I didn't read Corinna's message as thoroughly as I should have.
>> Sorry.
>>
>> That particular issue was supposed to have been fixed in Cygwin 1.7.17,
>> released in October 2012.
>
> Out of curiosity, I tried the test cases I found in that thread, more
> precisely here:
>
>    http://cygwin.com/ml/cygwin/2012-05/msg00434.html
>
>
> and the results are:
>
> $ gcc otto_test1.c -o otto_test1
> $ ./otto_test1
> Testing deferred pthread_cancel()
>
> Thread 0 starting (0x200102c0)
> Thread 1 starting (0x20010360)
> Thread 2 starting (0x20010400)
>
> Cancelling thread 2 (0x20010400)
> Thread 2 exiting (0x20010400)
> Cancelling thread 1 (0x20010360)
> Thread 1 exiting (0x20010360)
> Cancelling thread 0 (0x200102c0)
> Thread 0 exiting (0x200102c0)
>
> Thread 0 is gone (0x200102c0)
> Thread 1 is gone (0x20010360)
> Thread 2 is gone (0x20010400)
>
> $ gcc otto_test2.c -o otto_test2
> $ ./otto_test2
> Testing asynchronous pthread_cancel()
>
> Thread 0 starting (0x200102c0)
> Changing canceltype from 0 to 1
> Thread 1 starting (0x20010360)
> Changing canceltype from 0 to 1
> Thread 2 starting (0x20010400)
> Changing canceltype from 0 to 1
>
> Cancelling thread 2 (0x20010400)
> Thread 2 exiting (0x20010400)
> Cancelling thread 1 (0x20010360)
> Thread 1 exiting (0x20010360)
> Cancelling thread 0 (0x200102c0)
> Thread 0 exiting (0x200102c0)
>
> Thread 0 is gone (0x200102c0)
> Thread 1 is gone (0x20010360)
> Thread 2 is gone (0x20010400)
>
> $ gcc otto_test3.c -o otto_test3
> $ ./otto_test3
> Testing pthread_kill()
>
> Thread 0 starting (0x200102c0)
> Thread 1 starting (0x20010360)
> Thread 2 starting (0x20010400)
>
> Sending SIGUSR1 to thread 2 (0x20010400)
> Thread 2 executes signal handler (0x20010400)
> Thread 2 encountered an error: Interrupted system call (0x20010400)
> Sending SIGUSR1 to thread 1 (0x20010360)
> Thread 1 executes signal handler (0x20010360)
> Thread 1 encountered an error: Interrupted system call (0x20010360)
> Sending SIGUSR1 to thread 0 (0x200102c0)
> Thread 0 executes signal handler (0x200102c0)
> Thread 0 encountered an error: Interrupted system call (0x200102c0)
>
> Are the errors in the last test case to be expected under the 20130612
> snapshot (CYGWIN_NT-5.1, 1.7.21s 20130612 21:06:59, i686 Cygwin)?

I can replicate this on my system, consistently.  There's clearly a 
problem, but it's not the same as in the original Cygwin bug report.  In 
the present case, the signal is received by the right thread, but 
something goes wrong afterwards.

I'm attaching the test case for ease of reference.

Ken

--------------060004040501040900040907
Content-Type: text/plain; charset=windows-1252;
 name="otto_test3.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="otto_test3.c"

LyogaHR0cDovL2N5Z3dpbi5jb20vbWwvY3lnd2luLzIwMTItMDUvbXNnMDA0
MzQuaHRtbCAqLwoKI2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxwdGhy
ZWFkLmg+CiNpbmNsdWRlIDxzZW1hcGhvcmUuaD4KI2luY2x1ZGUgPHNpZ25h
bC5oPgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgoj
aW5jbHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KCnB0aHJl
YWRfdCB0aWRzWzNdOwpzZW1fdCBzZW1hcGhvcmU7CgpzdGF0aWMgdm9pZCBj
bGVhbnVwX2hhbmRsZXIodm9pZCAqYXJnKSB7CiAgaW50ICppbnRwdHIgPSAo
aW50Kilhcmc7CiAgcHRocmVhZF90IHNlbGYgPSBwdGhyZWFkX3NlbGYoKTsK
ICBmcHJpbnRmKHN0ZGVyciwgIlRocmVhZCAlaSBleGl0aW5nICglcClcbiIs
ICppbnRwdHIsIHNlbGYpOwp9CgpzdGF0aWMgdm9pZCogc2ltcGxldGhyZWFk
KHZvaWQgKmFyZykgewogIGludCAqaW50cHRyID0gKGludCopYXJnOwogIHB0
aHJlYWRfdCBzZWxmID0gcHRocmVhZF9zZWxmKCk7CiAgZnByaW50ZihzdGRl
cnIsICJUaHJlYWQgJWkgc3RhcnRpbmcgKCVwKVxuIiwgKmludHB0ciwgc2Vs
Zik7CgogIHB0aHJlYWRfY2xlYW51cF9wdXNoKCZjbGVhbnVwX2hhbmRsZXIs
IGludHB0cik7CgogIHdoaWxlICgxKSB7CiAgICBpZiAoc2VtX3dhaXQoJnNl
bWFwaG9yZSkgIT0gMCkgewogICAgICBmcHJpbnRmKHN0ZGVyciwgIlRocmVh
ZCAlaSBlbmNvdW50ZXJlZCBhbiBlcnJvcjogJXMgKCVwKVxuIiwKICAgICAg
ICAgICppbnRwdHIsIHN0cmVycm9yKGVycm5vKSwgc2VsZik7CiAgICB9IGVs
c2UgewogICAgICBmcHJpbnRmKHN0ZGVyciwgIlRocmVhZCAlaSB3b2tlIHVw
IGp1c3QgZmluZVxuIiwgKmludHB0cik7CiAgICB9CiAgfQoKICBwdGhyZWFk
X2NsZWFudXBfcG9wKDEpOwogIHJldHVybiBOVUxMOwp9CgpzdGF0aWMgdm9p
ZCBzaWd1c3IxX2hhbmRsZXIoaW50IHNpZ25hbCBfX2F0dHJpYnV0ZSgodW51
c2VkKSkpIHsKICBwdGhyZWFkX3Qgc2VsZiA9IHB0aHJlYWRfc2VsZigpOwog
IGludCB0bnVtID0gMDsKICB3aGlsZSAodG51bSA8IDMpIHsKICAgIGlmICh0
aWRzW3RudW1dID09IHNlbGYpIHsKICAgICAgYnJlYWs7CiAgICB9CiAgICB0
bnVtKys7CiAgfQoKICBmcHJpbnRmKHN0ZGVyciwgIlRocmVhZCAlaSBleGVj
dXRlcyBzaWduYWwgaGFuZGxlciAoJXApXG4iLCB0bnVtLCBzZWxmKTsKfQoK
c3RhdGljIHZvaWQgaW5zdGFsbF9oYW5kbGVyKHZvaWQpIHsKICBzdHJ1Y3Qg
c2lnYWN0aW9uIGFjdDsKICBhY3Quc2FfaGFuZGxlciA9ICZzaWd1c3IxX2hh
bmRsZXI7CiAgc2lnZW1wdHlzZXQoJihhY3Quc2FfbWFzaykpOwogIGFjdC5z
YV9mbGFncyA9IDA7CgogIGlmIChzaWdhY3Rpb24oU0lHVVNSMSwgJmFjdCwg
TlVMTCkgIT0gMCkgewogICAgZnByaW50ZihzdGRlcnIsICJDYW4ndCBzZXQg
c2lnbmFsIGhhbmRsZXI6ICVzXG4iLCBzdHJlcnJvcihlcnJubykpOwogICAg
ZXhpdCgxKTsKICB9CgogIHNpZ3NldF90IHNzZXQ7CiAgc2lnZW1wdHlzZXQo
JnNzZXQpOwogIHNpZ2FkZHNldCgmc3NldCwgU0lHVVNSMSk7CiAgaWYgKHNp
Z3Byb2NtYXNrKFNJR19VTkJMT0NLLCAmc3NldCwgTlVMTCkgIT0gMCkgewog
ICAgZnByaW50ZihzdGRlcnIsICJDYW4ndCB1bmJsb2NrIFNJR1VTUjE6ICVz
XG4iLCBzdHJlcnJvcihlcnJubykpOwogIH0KfQoKaW50IG1haW4oKSB7CiAg
ZnByaW50ZihzdGRlcnIsICJUZXN0aW5nIHB0aHJlYWRfa2lsbCgpXG5cbiIp
OwoKICBpbnQgaTsKICBpbnQgcmVzdWx0OwoKICBzZW1faW5pdCgmc2VtYXBo
b3JlLCAwLCAwKTsKICBpbnN0YWxsX2hhbmRsZXIoKTsKCiAgZm9yIChpPTA7
IGk8MzsgaSsrKSB7CiAgICBpbnQgKmludHB0ciA9IChpbnQqKW1hbGxvYyhz
aXplb2YoaW50KSk7CiAgICAqaW50cHRyID0gaTsKICAgIHJlc3VsdCA9IHB0
aHJlYWRfY3JlYXRlKHRpZHMraSwgTlVMTCwgJnNpbXBsZXRocmVhZCwgaW50
cHRyKTsKICAgIGlmIChyZXN1bHQgIT0gMCkgewogICAgICBmcHJpbnRmKHN0
ZGVyciwgIkNhbid0IGNyZWF0ZSB0aHJlYWQ6ICVzXG4iLCBzdHJlcnJvcihy
ZXN1bHQpKTsKICAgICAgcmV0dXJuIDE7CiAgICB9CiAgfQoKICBzbGVlcCgx
KTsKICBpbnN0YWxsX2hhbmRsZXIoKTsKICBmcHJpbnRmKHN0ZGVyciwgIlxu
Iik7CgogIGludCBtYWluaW50ID0gNDI7CiAgcHRocmVhZF9jbGVhbnVwX3B1
c2goJmNsZWFudXBfaGFuZGxlciwgJm1haW5pbnQpOwoKICBmb3IgKGk9Mjsg
aT49MDsgaS0tKSB7CiAgICBmcHJpbnRmKHN0ZGVyciwgIlNlbmRpbmcgU0lH
VVNSMSB0byB0aHJlYWQgJWkgKCVwKVxuIiwgaSwgdGlkc1tpXSk7CiAgICBy
ZXN1bHQgPSBwdGhyZWFkX2tpbGwodGlkc1tpXSwgU0lHVVNSMSk7CiAgICBp
ZiAocmVzdWx0ICE9IDApIHsKICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJv
ciBkdXJpbmcgcHRocmVhZF9raWxsOiAlc1xuIiwgc3RyZXJyb3IocmVzdWx0
KSk7CiAgICB9CiAgICBzbGVlcCgxKTsKICB9CgogIHB0aHJlYWRfY2xlYW51
cF9wb3AoMCk7CiAgcmV0dXJuIDA7Cn0K


--------------060004040501040900040907
Content-Type: text/plain; charset=us-ascii

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