From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99946 invoked by alias); 7 Jul 2019 02:16:25 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 99939 invoked by uid 89); 7 Jul 2019 02:16:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=varda, Varda X-HELO: mail-io1-f48.google.com Received: from mail-io1-f48.google.com (HELO mail-io1-f48.google.com) (209.85.166.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 07 Jul 2019 02:16:24 +0000 Received: by mail-io1-f48.google.com with SMTP id q22so5406666iog.4 for ; Sat, 06 Jul 2019 19:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YooNbMZMwUlQTiOkxOl+ohutGOJHBnY+TKy4uhhZ4Jg=; b=ZmAklq80dj+z7c9G9PtMzHjA3ES6sIT38QQXIA3jOvLBGkPgjbjEP+GeWBh9jLds3t Hn2VN3a/7X4bjz7VkYNaQC+kkQhjdHpOe7b56ezed/acJb9YbNs6fhUVeS5o1K6sjSZn 4yw8ecqDKryZVodCghawbV2yghx+V6pxojwJI= MIME-Version: 1.0 References: In-Reply-To: From: Kenton Varda Date: Sun, 07 Jul 2019 02:16:00 -0000 Message-ID: Subject: Re: sigpending() incorrectly returns signals pending on other threads To: cygwin@cygwin.com Content-Type: multipart/mixed; boundary="000000000000e9f91d058d0de9f9" X-SW-Source: 2019-07/txt/msg00052.txt.bz2 --000000000000e9f91d058d0de9f9 Content-Type: text/plain; charset="UTF-8" Content-length: 1808 I found a second problem which may or may not be related: If two threads use pthread_kill() to send each other the same signal, such that the signal should be separately pending on both threads at the same time, only one of the two signals is actually queued. It seems that pthread_kill() is ignored if the same signal is already pending on some other thread. I've attached another demo program where two threads send each other the same signal at the same time. On Linux and Mac, both are delivered. On Cygwin, one or the other signal is delivered randomly, but never both. Same version: CYGWIN_NT-6.1 3.0.7(0.338/5/3) 2019-04-30 18:08 -Kenton On Sat, Jul 6, 2019 at 3:46 PM Kenton Varda wrote: > > Hello Cygwin, > > According to the (Linux) man page: "sigpending() returns the set of > signals that are pending for delivery to the calling thread" > > However, on Cygwin, sigpending() seems to return the set of signals > pending on any thread, as shown in the attached test program. > > Among other things, this can cause deadlocks in programs which use > sigpending() to check for pending signals, then use sigsuspend() to > induce delivery of the specific signals that are pending. Because the > signal is not actually pending on the current thread, sigsuspend() > will unexpectedly block, potentially forever. > > Output of test program: > $ uname -srv > CYGWIN_NT-6.1 3.0.7(0.338/5/3) 2019-04-30 18:08 > $ gcc -std=c11 -Wall test-sigpending.c -o test-sigpending -pthread && > ./test-sigpending > sending signal to child thread with pthread_kill()... > sigpending() says signal is pending in main thread (WRONG) > sigpending() says signal is pending in child thread (CORRECT) > received signal in child thread (CORRECT) > > The program works correctly on Linux. > > -Kenton --000000000000e9f91d058d0de9f9 Content-Type: text/x-csrc; charset="US-ASCII"; name="test-pthread-kill.c" Content-Disposition: attachment; filename="test-pthread-kill.c" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jxsb8b5o0 Content-length: 2989 I2RlZmluZSBfR05VX1NPVVJDRSAxCgojaW5jbHVkZSA8cHRocmVhZC5oPgoj aW5jbHVkZSA8c2lnbmFsLmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVk ZSA8dW5pc3RkLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0 cmluZy5oPgoKI2RlZmluZSBzeXMoY29kZSkgaWYgKChjb2RlKSA8IDApIHsg cGVycm9yKCNjb2RlKTsgZXhpdCgxKTsgfQoKcHRocmVhZF90IG1haW5UaHJl YWQ7CnB0aHJlYWRfdCBjaGlsZFRocmVhZDsKCnVuc2lnbmVkIGludCByZWNl aXB0cyA9IDA7Cgp2b2lkIGhhbmRsZXIoaW50IHNpZ25vLCBzaWdpbmZvX3Qq IHNpZ2luZm8sIHZvaWQqIGNvbnRleHQpIHsKICBpZiAocHRocmVhZF9lcXVh bChwdGhyZWFkX3NlbGYoKSwgbWFpblRocmVhZCkpIHsKICAgIHByaW50Zigi cmVjZWl2ZWQgc2lnbmFsIGluIG1haW4gdGhyZWFkXG4iKTsKICAgIF9fYXRv bWljX2ZldGNoX29yKCZyZWNlaXB0cywgMSwgX19BVE9NSUNfUkVMQVhFRCk7 CiAgfSBlbHNlIGlmIChwdGhyZWFkX2VxdWFsKHB0aHJlYWRfc2VsZigpLCBj aGlsZFRocmVhZCkpIHsKICAgIHByaW50ZigicmVjZWl2ZWQgc2lnbmFsIGlu IGNoaWxkIHRocmVhZFxuIik7CiAgICBfX2F0b21pY19mZXRjaF9vcigmcmVj ZWlwdHMsIDIsIF9fQVRPTUlDX1JFTEFYRUQpOwogIH0gZWxzZSB7CiAgICBw cmludGYoInJlY2VpdmVkIHNpZ25hbCBpbiBvdGhlciB0aHJlYWQgKD8pXG4i KTsKICB9Cn0KCnZvaWQqIHRocmVhZE1haW4odm9pZCogcGFyYW0pIHsKICAv LyBTZW5kIFNJR1VTUjEgdG8gbWFpbiB0aHJlYWQuCiAgcHRocmVhZF9raWxs KG1haW5UaHJlYWQsIFNJR1VTUjEpOwoKICAvLyBHaXZlIG1haW4gdGhyZWFk IHRpbWUgdG8gc2VuZCB1cyBTSUdVU1IxLgogIHVzbGVlcCgxMDAwMDApOwoK ICAvLyBVbmJsb2NrIFNJR1VTUjEgdG8gc2VlIGlmIGl0IGdldHMgZGVsaXZl cmVkLgogIHNpZ3NldF90IG1hc2s7CiAgc3lzKHNpZ2VtcHR5c2V0KCZtYXNr KSk7CiAgc3lzKHNpZ2FkZHNldCgmbWFzaywgU0lHVVNSMSkpOwogIHN5cyhw dGhyZWFkX3NpZ21hc2soU0lHX1VOQkxPQ0ssICZtYXNrLCBOVUxMKSk7Cgog IHJldHVybiBOVUxMOwp9CgppbnQgbWFpbigpIHsKICAvLyBSZWdpc3RlciBh IHNpZ25hbCBoYW5kbGVyIGZvciBTSUdVU1IxLgogIHN0cnVjdCBzaWdhY3Rp b24gYWN0aW9uOwogIG1lbXNldCgmYWN0aW9uLCAwLCBzaXplb2YoYWN0aW9u KSk7CiAgYWN0aW9uLnNhX3NpZ2FjdGlvbiA9ICZoYW5kbGVyOwogIGFjdGlv bi5zYV9mbGFncyA9IFNBX1NJR0lORk87CiAgc3lzKHNpZ2FjdGlvbihTSUdV U1IxLCAmYWN0aW9uLCBOVUxMKSk7CgogIC8vIEJsb2NrIFNJR1VTUjEuCiAg c2lnc2V0X3QgbWFzazsKICBzeXMoc2lnZW1wdHlzZXQoJm1hc2spKTsKICBz eXMoc2lnYWRkc2V0KCZtYXNrLCBTSUdVU1IxKSk7CiAgc3lzKHB0aHJlYWRf c2lnbWFzayhTSUdfQkxPQ0ssICZtYXNrLCBOVUxMKSk7CgogIC8vIFN0YXJ0 IGNoaWxkIHRocmVhZC4KICBtYWluVGhyZWFkID0gcHRocmVhZF9zZWxmKCk7 CiAgaWYgKHB0aHJlYWRfY3JlYXRlKCZjaGlsZFRocmVhZCwgTlVMTCwgJnRo cmVhZE1haW4sIE5VTEwpIDwgMCkgewogICAgZnByaW50ZihzdGRlcnIsICJw dGhyZWFkX2NyZWF0ZSBmYWlsZWRcbiIpOwogICAgZXhpdCgxKTsKICB9Cgog IC8vIFNlbmQgU0lHVVNSMSB0byBjaGlsZCB0aHJlYWQuCiAgcHRocmVhZF9r aWxsKGNoaWxkVGhyZWFkLCBTSUdVU1IxKTsKCiAgLy8gVW5ibG9jayBTSUdV U1IxIHRvIHNlZSBpZiBpdCBnZXRzIGRlbGl2ZXJlZCB0byB0aGlzIHRocmVh ZC4KICBzeXMoc2lnZW1wdHlzZXQoJm1hc2spKTsKICBzeXMoc2lnYWRkc2V0 KCZtYXNrLCBTSUdVU1IxKSk7CiAgc3lzKHB0aHJlYWRfc2lnbWFzayhTSUdf VU5CTE9DSywgJm1hc2ssIE5VTEwpKTsKCiAgcHRocmVhZF9qb2luKGNoaWxk VGhyZWFkLCBOVUxMKTsKCiAgaWYgKHJlY2VpcHRzID09IDMpIHsKICAgIHBy aW50ZigiYm90aCB0aHJlYWRzIHJlY2VpdmVkIHNpZ25hbCAoQ09SUkVDVClc biIpOwogIH0gZWxzZSBpZiAocmVjZWlwdHMgPT0gMSB8fCByZWNlaXB0cyA9 PSAyKSB7CiAgICBwcmludGYoIm9ubHkgb25lIHRocmVhZCByZWNlaXZlZCBz aWduYWwgKFdST05HKVxuIik7CiAgfSBlbHNlIHsKICAgIHByaW50Zigic2ln bmFsIG5vdCBkZWxpdmVyZWQgYXQgYWxsIChXUk9ORylcbiIpOwogIH0KfQoK --000000000000e9f91d058d0de9f9 Content-Type: text/plain; charset=us-ascii Content-length: 219 -- 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 --000000000000e9f91d058d0de9f9--