Recently, test_ssl has been failing intermittently but frequently on macOS buildbots, see for example here (but look at the first failure; the re-run is #126499).
If read() in a ThreadedEchoServer's ConnectionHandler thread raises OSError (except ConnectionError), the ConnectionHandler shuts down the entire server, preventing further connections.
As far as I can see, this is done to avoid the server thread getting stuck, forgotten, in its accept loop. However, since 2011 (5b95eb9) the server is used as a context manager, and its __exit__ does stop() and join().
(I'm not sure if we always used with since that commit, but currently we do.)
The most common failure I saw is the following. Note that it's the third connect call in this test: presumably, if the server thread started shutting down after the first connect it had enough time by now. But sometimes the same happens with the second connect, in this test or another one.
Traceback (most recent call last):
File "/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/test_ssl.py", line 1897, in test_connect_with_context
s.connect(self.server_addr)
~~~~~~~~~^^^^^^^^^^^^^^^^^^
File "/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/ssl.py", line 1405, in connect
self._real_connect(addr, False)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
File "/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/ssl.py", line 1392, in _real_connect
super().connect(addr)
~~~~~~~~~~~~~~~^^^^^^
ConnectionRefusedError: [Errno 61] Connection refused
I'll send a PR soon.
Linked PRs
Recently,
test_sslhas been failing intermittently but frequently on macOS buildbots, see for example here (but look at the first failure; the re-run is #126499).If
read()in aThreadedEchoServer'sConnectionHandlerthread raisesOSError(exceptConnectionError), theConnectionHandlershuts down the entire server, preventing further connections.As far as I can see, this is done to avoid the server thread getting stuck, forgotten, in its accept loop. However, since 2011 (5b95eb9) the server is used as a context manager, and its
__exit__doesstop()andjoin().(I'm not sure if we always used
withsince that commit, but currently we do.)The most common failure I saw is the following. Note that it's the third
connectcall in this test: presumably, if the server thread started shutting down after the firstconnectit had enough time by now. But sometimes the same happens with the secondconnect, in this test or another one.I'll send a PR soon.
Linked PRs