From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 034C1388C025 for ; Mon, 7 Dec 2020 07:58:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 034C1388C025 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 0B77waOr095547 for ; Sun, 6 Dec 2020 23:58:36 -0800 (PST) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpdV7FSFA; Sun Dec 6 23:58:27 2020 Subject: Re: python fails asyncio tests (py 3.7 & 3.8) From: Mark Geisert To: cygwin@cygwin.com References: <5233b4bb-8e9e-b6bd-0a56-c6ce5aa43f42@JC-Bell.com> Message-ID: Date: Sun, 6 Dec 2020 23:58:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 07:58:38 -0000 [Replying to myself...] Mark Geisert wrote: > Jim Bell wrote: >> On 2020-11-21 5:59 AM, Jim Bell wrote: >>> The standard python asyncio tests hang. >>> >>>         cd /usr/lib/python3.8/test >>> >>>         python3.8 test_asyncore.py -v >>> >>> [...] >> Using strace, stripping down this very repeatable test, and grabbing the >> source-code snapshot, it looks like winsup/cygwin/select.cc socket_cleanup() is >> waiting forever for the thread to go away. >> >> strace: >> >>    121 6732185 [main] python3.8 13329 select_stuff::cleanup: calling cleanup rout >> ines >>    178 6732363 [main] python3.8 13329 socket_cleanup: si 0x800290E10 si->thread 0 >> x18023E758 >> - [...] > Thanks for the report and especially for the initial debugging you've done.  I've > reproduced the issue on my test machine.  No need to supply 'cygcheck -svr' at > this point.  I'll investigate this further and keep you posted (on the Cygwin > mailing list). The problem is actually further down in the guts of Cygwin's Unix Domain Socket handling. Specifically it has to do with the credential passing between client and server ends of a connection as part of its setup. There is a workaround for this problem that involves turning off socket option SO_PEERCRED on both the connecting and listening sockets. Unfortunately there's another problem. With the current Cygwin DLL build you'll get an EINVAL error trying to do that setsockopt() operation. I have submitted a patch that fixes this 2nd problem. A future Cygwin snapshot TBA will contain this patch. As for the test script errors you reported, I can submit a workaround patch that would make its way into the Python3.8 tests. I am unsure at the moment which Cygwin package contains those tests but I can figure that out. Otherwise, I could tell you what needs to be patched in test_asyncore.py and you could edit the script yourself to fix this locally for yourself. Let me know how you'd like to proceed, when you have a chance. ..mark