Closed noxxi closed 3 years ago
From steffen_ullrich@genua.de on 2017-08-09 10:16:48 :
Am Sa 15. Jul 2017, 15:51:03, sinan@unur.com schrieb:
Hello:
I am not sure what the cause of these failures is. I ran the test script multiple times to see if the problem was transient. This more an FYI at this point.
Thanks for the bugreport.
I get similar problems with perl 5.22 on the Linux subsystem. Your output and mine output suggest, that nonblocking IO is not yet properly implemented, maybe only in the context of specific relations between the client and server (i.e. local machine, client is child of server...).
Since I think that the Linux subsystem is not yet announced as ready for production I will not try to fix the problem at the moment but just hope that it goes away by itself with future changes to the Windows subsystem. I will keep the bug open though.
From pmperry@cpan.org on 2020-02-18 14:17:15 :
Windows 10, Strawberry Perl 5.26.1, CPAN upgrade from 2.066 to 2.067.
First time through, hung on t/verify_fingerprint.t. Tried to upgrade again, this time answered "no" to "run external tests". This time two tests failed on t/nonblock.t (13 and 26), but verify_fingerprint.t passed.
From pmperry@cpan.org on 2020-03-31 13:37:51 :
Tried upgrade (via cpan) 2.066 to 2.068. With external tests enabled, passed verify_fingerprint.t, but still fails nonblock.t (2/27 tests). Windows 10, Strawberry Perl 5.26.1.
From pmperry@cpan.org on 2020-04-04 13:28:01 :
On Tue Mar 31 09:37:51 2020, PMPERRY wrote:
Tried upgrade (via cpan) 2.066 to 2.068. With external tests enabled, passed verify_fingerprint.t, but still fails nonblock.t (2/27 tests). Windows 10, Strawberry Perl 5.26.1. Well, this gets stranger and stranger. Tried same upgrade as before. nonblock.t still fails, but verify_fingerprint.t is hanging again at 1/13 (running external tests).
From pmperry@cpan.org on 2021-01-23 18:49:25 :
On Sat Apr 04 09:28:01 2020, PMPERRY wrote:
On Tue Mar 31 09:37:51 2020, PMPERRY wrote:
Tried upgrade (via cpan) 2.066 to 2.068. With external tests enabled, passed verify_fingerprint.t, but still fails nonblock.t (2/27 tests). Windows 10, Strawberry Perl 5.26.1. Well, this gets stranger and stranger. Tried same upgrade as before. nonblock.t still fails, but verify_fingerprint.t is hanging again at 1/13 (running external tests).
Tried update to 2.069, same failure as before.
From jkeenan@cpan.org on 2021-02-14 22:03:34 :
On Wed Aug 09 06:16:48 2017, SULLR wrote:
Am Sa 15. Jul 2017, 15:51:03, sinan@unur.com schrieb:
Hello:
I am not sure what the cause of these failures is. I ran the test script multiple times to see if the problem was transient. This more an FYI at this point.
Thanks for the bugreport.
I get similar problems with perl 5.22 on the Linux subsystem. Your output and mine output suggest, that nonblocking IO is not yet properly implemented, maybe only in the context of specific relations between the client and server (i.e. local machine, client is child of server...).
Since I think that the Linux subsystem is not yet announced as ready for production I will not try to fix the problem at the moment but just hope that it goes away by itself with future changes to the Windows subsystem. I will keep the bug open though.
Today I attempted to install IO-Socket-SSL-2.069 against Perl 5 blead (397e6c111f) on FreeBSD-12. I got failures in t/nonblock.t similar to those reported by Sinan Unur in 2017.
#####
[perlmonger: IO-Socket-SSL-2.069-0] $ bleadprove -vb t/nonblock.t
t/nonblock.t ..
1..27
ok # [server] Server Initialization
# connect in progress
# claims that socket is already connected
ok # [client] client tcp connect
# wrote 9 bytes
ok # [client] write plain text
ok # [server] tcp accept
ok # [server] received plain text
ok # [server] upgrade to_client to IO::Socket::SSL
ok # [client] upgrade client to IO::Socket::SSL
# SSL wants a read first
ok # [client] connected
ok # [client] nonblocking connect with 1 attempts
# sndbuf=8192
ok # [server] ssl accept handshake done
ok # [server] received client message
# $!=Resource temporarily unavailable $SSL_ERROR=SSL wants a write first send=2570
# wait for write
# read 30000 (1 r/w attempts)
# fail can_write
not ok # [client] syswrite
ok # [client] multiple write attempts
ok # [client] 30000 bytes send
# connect in progress
# claims that socket is already connected
ok # [client] client tcp connect
# wrote 9 bytes
ok # [client] write plain text
ok # [server] tcp accept
ok # [server] received plain text
ok # [server] upgrade to_client to IO::Socket::SSL
ok # [client] upgrade client to IO::Socket::SSL
# SSL wants a read first
ok # [client] connected
# sndbuf=8192
ok # [server] ssl accept handshake done
ok # [server] nonblocking accept_SSL with 2 attempts
ok # [server] received client message
# $!=Resource temporarily unavailable $SSL_ERROR=SSL wants a write first send=2570
# wait for write
# read 30000 (2 r/w attempts)
# fail can_write
not ok # [client] syswrite
ok # [client] multiple write attempts
ok # [client] 30000 bytes send
Failed 2/27 subtests
Test Summary Report
-------------------
t/nonblock.t (Wstat: 0 Tests: 27 Failed: 2)
Failed tests: 12, 25
Files=1, Tests=27, 80 wallclock secs ( 0.03 usr 0.02 sys + 0.98 cusr 0.18 csys = 1.21 CPU)
Result: FAIL
#####
Can you investigate?
Thank you very much. Jim Keenan
From steffen_ullrich@genua.de on 2021-02-14 23:35:53 :
Today I attempted to install IO-Socket-SSL-2.069 against Perl 5 blead (397e6c111f) on FreeBSD-12. I got failures in t/nonblock.t similar to those reported by Sinan Unur in 2017.
Thanks for reporting but please note that this bug here is about Perl on Linux subsystem in Windows. While it might be related I would ask you to report a new bug and also add as much information as needed to reproduce the issue, notably
Please also note that rt.cpan.org stops service in a few weeks, so please report the problem at github instead.
Error pattern looks exactly the same as on #102 . Since that issue was fixed I'll close this one too. If it does not work please reopen or create a new issue.
Migrated from rt.cpan.org #122499 (status was 'open')
Requestors:
From sinan@unur.com on 2017-07-15 19:51:03 :
Hello:
I am not sure what the cause of these failures is. I ran the test script multiple times to see if the problem was transient. This more an FYI at this point.