classification
Title: SSL: test_connect_ex_error fails with EWOULDBLOCK
Type: behavior Stage: resolved
Components: Tests Versions: Python 3.4, Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, christian.heimes, pitrou, python-dev, valhallasw
Priority: normal Keywords: patch

Created on 2013-12-07 16:48 by christian.heimes, last changed 2016-01-08 04:35 by martin.panter. This issue is now closed.

Files
File name Uploaded Description Edit
issue19919.patch christian.heimes, 2013-12-16 20:06 review
Messages (11)
msg205467 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-12-07 16:48
On Windows the test_connect_ex_error sometimes fails with EWOULDBLOCK instead of ECONNREFUSED. Valhallasw sometimes gets the same error with an Ubuntu VM on Windows. This might be a Windows socket issue. 

======================================================================
FAIL: test_connect_ex_error (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ssl.py", line 1205, in test_connect_ex_error
    s.connect_ex(("svn.python.org", 444)))
AssertionError: 10061 != 10035

>>> for k, v in errno.__dict__.items():
...     if v == 10035: print(k)
...
EWOULDBLOCK
WSAEWOULDBLOCK
>>> for k, v in errno.__dict__.items():
...     if v == 10061: print(k)
...
WSAECONNREFUSED
ECONNREFUSED
msg205469 - (view) Author: Merlijn van Deen (valhallasw) * Date: 2013-12-07 16:58
My error is slightly different:

$ ./python -i -c "from test.test_ssl import *; support.run_unittest(NetworkedTests)"
(...)

======================================================================
FAIL: test_connect_ex_error (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/valhallasw/src/cpython/Lib/test/test_ssl.py", line 1205, in test_connect_ex_error
    s.connect_ex(("svn.python.org", 444)))
AssertionError: 111 != 11

----------------------------------------------------------------------
Ran 15 tests in 33.590s

FAILED (failures=1, skipped=1)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/valhallasw/src/cpython/Lib/test/support/__init__.py", line 1719, in run_unittest
    _run_suite(suite)
  File "/home/valhallasw/src/cpython/Lib/test/support/__init__.py", line 1694, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/home/valhallasw/src/cpython/Lib/test/test_ssl.py", line 1205, in test_connect_ex_error
    s.connect_ex(("svn.python.org", 444)))
AssertionError: 111 != 11

>>> errno.errorcode[11]
'EAGAIN'
>>> errno.errorcode[111]
'ECONNREFUSED'

This is on Ubuntu x64 12.04 LTS, under VirtualBox 4.3.4 (r91027), running on Windows 7 Professional (6.1.7601).

OpenSSL versions as returned by test_ssl:

$ ./python -m Lib.test.test_ssl
test_ssl: testing with 'OpenSSL 1.0.1 14 Mar 2012' (1, 0, 1, 0, 15)
          under Linux ('debian', 'wheezy/sid', '')
          HAS_SNI = True
          OP_ALL = 0x800003ff
          OP_NO_TLSv1_1 = 0x10000000
msg205470 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-12-07 17:01
EAGAIN          Resource temporarily unavailable (may be the same value as EWOULDBLOCK) (POSIX.1)

Can you please check of EAGAIN and EWOULDBLOCK are the same value on your Linux box? They are the same on my box:

>>> import errno
>>> errno.EAGAIN, errno.EWOULDBLOCK
(11, 11)
msg205471 - (view) Author: Merlijn van Deen (valhallasw) * Date: 2013-12-07 17:03
Yes, they are.

>>> errno.EWOULDBLOCK
11

EAGAIN and EWOULDBLOCK are the only two with that errno:
>>> [(k,v) for (k,v) in errno.__dict__.items() if v==11]
[('EWOULDBLOCK', 11), ('EAGAIN', 11)]

111 is just ECONNREFUSED:
>>> [(k,v) for (k,v) in errno.__dict__.items() if v==111]
[('ECONNREFUSED', 111)]
msg205474 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-12-07 17:27
The explanation for EAGAIN is in the test just above (test_timeout_connect_ex). Read it.
msg205476 - (view) Author: Merlijn van Deen (valhallasw) * Date: 2013-12-07 17:46
OK. I did some network sniffing; inside the VM, this is what I see:

$ sudo tshark host 82.94.164.164
tshark: Lua: Error during loading:
 [string "/usr/share/wireshark/init.lua"]:45: dofile has been disabled
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
  0.000000    10.0.2.15 -> 82.94.164.164 TCP 74 52719 > snpp [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=10175140 TSecr=0 WS=16

while on the host, this is what I see:
1	0.000000000	192.168.1.122	82.94.164.164	TCP	66	49909 > snpp [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
2	0.029908000	82.94.164.164	192.168.1.122	TCP	54	snpp > 49909 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0


Basically, the RST sent by the server never reaches the VM. This might actually happen in other NAT-ed situations, too, I guess.

But even if this is a VM issue, it *does* make the tests misbehave. Maybe receiving EAGAIN should result in a test skip instead of an error?
msg206358 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-12-16 20:06
Here is a patch.
msg206359 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-12-16 20:10
Looks fine to me.
msg206361 - (view) Author: Roundup Robot (python-dev) Date: 2013-12-16 20:17
New changeset 40955ae17472 by Christian Heimes in branch '3.3':
Issue #19919: Fix flacky SSL test. connect_ex() sometimes returns
http://hg.python.org/cpython/rev/40955ae17472

New changeset 593c3fa7aa2c by Christian Heimes in branch 'default':
Issue #19919: Fix flacky SSL test. connect_ex() sometimes returns
http://hg.python.org/cpython/rev/593c3fa7aa2c
msg206362 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-12-16 20:17
Thanks!
msg222840 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-07-12 13:54
Accidentally set to pending?
History
Date User Action Args
2016-01-08 04:35:17martin.pantersetstatus: open -> closed
2014-07-12 13:54:54BreamoreBoysetstatus: pending -> open
nosy: + BreamoreBoy
messages: + msg222840

2013-12-16 20:17:45christian.heimessetstatus: open -> pending
resolution: fixed
messages: + msg206362

stage: patch review -> resolved
2013-12-16 20:17:13python-devsetnosy: + python-dev
messages: + msg206361
2013-12-16 20:10:32pitrousetstage: patch review
messages: + msg206359
versions: + Python 3.3
2013-12-16 20:06:25christian.heimessetfiles: + issue19919.patch
keywords: + patch
messages: + msg206358
2013-12-07 17:46:42valhallaswsetmessages: + msg205476
2013-12-07 17:27:16pitrousetnosy: + pitrou
messages: + msg205474
2013-12-07 17:03:50valhallaswsetmessages: + msg205471
2013-12-07 17:01:25christian.heimessetmessages: + msg205470
2013-12-07 16:58:39valhallaswsetnosy: + valhallasw
messages: + msg205469
2013-12-07 16:48:37christian.heimescreate