This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: test_ssl with connect_ex don't handle unreachable server correctly
Type: behavior Stage: needs patch
Components: Tests Versions:
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, christian.heimes, ezio.melotti, neologix, pitrou
Priority: normal Keywords:

Created on 2012-12-24 11:41 by neologix, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg178051 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2012-12-24 11:41
test_ssl tests calling connect_ex don't handle unreachable servers properly:
Resource '' is not available
Resource '' is not available
test test_ssl failed -- Traceback (most recent call last):
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/test/", line 246, in test_connect_ex
    self.assertEqual(0, s.connect_ex(("", 443)))
AssertionError: 0 != None

support.transient doesn't help here since no exception is raised.
Note that I'm not sure that connect_ex returning None is normal in the first place...

There's a related failure on OpenBSD/NetBSD  buildbots:
test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok

ERROR: test_non_blocking_connect_ex (test.test_ssl.NetworkedTests)
Traceback (most recent call last):
  File "/home/cpython/buildslave/3.x.snakebite-openbsd51-amd64-1/build/Lib/test/", line 685, in test_non_blocking_connect_ex[], [s], [], 5.0)
OSError: [Errno 22] Invalid argument

I guess that connect() can't succeed because of an unreachable host/connection refused, and the subsequent select() fails with EINVAL. This is most likely a kernel bug, select should report the socket as ready for write (one could then use getsockopt() to find the actual error).
msg178404 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-12-28 17:55
> support.transient doesn't help here since no exception is raised

An exception can still be raised in do_handshake(), which is called when the connection succeeds. But, yes, it's otherwise useless.

> Note that I'm not sure that connect_ex returning None is normal in the 
> first place

It is not. The 2.7 implementation currently calls socket.connect() and catches socket errors, while the 3.2 implementation directly calls socket.connect_ex(). This means the 2.7 implementation will unwillingly catch name resolution errors, and other issues:

>>> socket.socket().connect_ex(("", 443))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/27/Lib/", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.gaierror: [Errno -5] No address associated with hostname
>>> ssl.wrap_socket(socket.socket()).connect_ex(("", 443))

I will backport the 3.2 implementation of connect_ex() in order to fix this inconsistency. Unfortunately there is no easy way to test for it.
msg183376 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-03-03 14:07
Is this still an issue?
msg221989 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-30 22:16
Does the backport mentioned in msg178404 still need doing, can this be closed as "out of date" or "won't fix" or what?
msg275033 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-08 14:59
It's probably out of date :)

Please reopen if you still see this issue.
Date User Action Args
2022-04-11 14:57:39adminsetgithub: 60967
2016-09-08 14:59:03christian.heimessetstatus: open -> closed

nosy: + christian.heimes
messages: + msg275033

resolution: out of date
2014-06-30 22:16:28BreamoreBoysetnosy: + BreamoreBoy
messages: + msg221989
2013-03-03 14:07:56ezio.melottisetnosy: + ezio.melotti
messages: + msg183376
2012-12-28 17:55:32pitrousetmessages: + msg178404
2012-12-24 11:41:48neologixcreate