classification
Title: test_socket fails occassionaly in teardown: AssertionError: [Errno 57] Socket is not connected
Type: behavior Stage:
Components: macOS, Tests Versions: Python 3.0, Python 3.1, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: mark.dickinson, oefe
Priority: normal Keywords: patch

Created on 2008-11-23 21:29 by oefe, last changed 2009-01-15 15:38 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
issue4397.patch mark.dickinson, 2008-12-17 21:44
socket_bug.py mark.dickinson, 2009-01-15 14:01 socket.shutdown failing example on OS X
Messages (5)
msg76276 - (view) Author: Martina Oefelein (oefe) Date: 2008-11-23 21:29
test_socket fails randomly in about 1 of 50 iterations (MacOS X 10.5.5 
intel):

$ for ((;;)); do DYLD_FRAMEWORK_PATH=/Users/martina/Downloads/Python-
3.0rc3: ./python.exe -E -bb ./Lib/test/regrtest.py -l test_socket;done
test_socket
1 test OK.

...

test_socket
test test_socket failed -- Traceback (most recent call last):
  File "/Users/martina/Downloads/Python-3.0rc3/Lib/test/test_socket.py", 
line 121, in _tearDown
    self.fail(msg)
AssertionError: [Errno 57] Socket is not connected

1 test failed:
    test_socket
test_socket
1 test OK.

...
msg77988 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-12-17 21:44
Thanks for the report.  I can reproduce this both on the py3k branch and the trunk.  It looks as though there's a race condition 
in the testShutDown/_testShutDown pair of methods in SocketConnectedTest.  If you add the line

time.sleep(0.01)

to the middle of the _testShutDown method in test_socket.py (between the self.serv_conn.send() and the self.serv_conn.shutdown), 
you'll probably find that this random occasional failure becomes a 99.9% reliable failure.

As far as I can tell, this is just a bug in test_socket itself, rather than a problem with the socket module.  I also can't see 
any reason why it should be Mac specific, but I don't have anything else handy to test on right now.

Suggested fix:  don't let testShutDown exit until after _testShutdown has executed the shutdown method.  Use a threading Event to 
make this work.  The attached patch (against the trunk) appears to fix the problem for me.  Martina, if you're in a position to 
test the patch, feedback would be welcome.

It would be good if someone could review this for sanity;  I'm a complete novice when it comes to threading (and sockets, for that 
matter).
msg79897 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-01-15 14:01
Hmm.  I take it back:  this *does* appear to be OS X specific.
I've attached a small (17-line) example that fails with
the Errno 57 error on OS X, but passes on the Linux machines I tested.

In this example, it appears that when 'conn.close()' is called by the 
server, the client socket 'cli' is automatically disconnected, hence
the shutdown failure.  On Linux that doesn't happen.

Can anyone shed any light on this, and/or suggest what should be done?
msg79899 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-01-15 15:10
Found a better (one-line) fix.  Fixed in the trunk in r68611.
Will port to 2.6, 3.0, 3.1.
msg79900 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-01-15 15:38
Fixed in 2.6, 3.0, 3.1.
History
Date User Action Args
2009-01-15 15:38:42mark.dickinsonsetstatus: open -> closed
messages: + msg79900
2009-01-15 15:10:04mark.dickinsonsetresolution: fixed
messages: + msg79899
versions: - Python 2.7
2009-01-15 14:01:46mark.dickinsonsetfiles: + socket_bug.py
messages: + msg79897
components: + macOS
stage: patch review ->
2008-12-17 21:44:33mark.dickinsonsetfiles: + issue4397.patch
priority: normal
components: - Library (Lib), macOS
versions: + Python 2.6, Python 3.1, Python 2.7
keywords: + patch
nosy: + mark.dickinson
messages: + msg77988
stage: patch review
2008-11-23 21:29:09oefecreate