test_socket failure on FreeBSD
Below is the output of test_socket with the -v option, from a CVS tree of about 1915 UTC June 18. FreeBSD 4.4, gcc 2.95.3 (-g -O3). In speaking up now, I'm making the assumption that the non-blocking socket changes should be complete, modulo bugfixes. If this is not the case, please let me know, and I'll wait for the situation to stabilise. Otherwise, is there any more info I can (attempt to) provide? I tried "print"ing the addr variable when running the test, and just get "ERROR" (sans quotes of course). I've not yet tried to build the OS/2 port with the current CVS code, so I don't yet know what the situation is there. Won't have much time to dig until the weekend... -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370 andymac@pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia ---------- Forwarded message ---------- Date: Wed, 19 Jun 2002 22:13:45 +1000 (EST) {...} test_socket Testing for mission critical constants. ... ok Testing getservbyname(). ... ok Testing getsockopt(). ... ok Testing hostname resolution mechanisms. ... ok Making sure getnameinfo doesn't crash the interpreter. ... ok Testing for existance of non-crucial constants. ... ok Testing reference count for getnameinfo. ... ok Testing setsockopt(). ... ok Testing getsockname(). ... ok Testing that socket module exceptions. ... ok Testing fromfd(). ... ok Testing receive in chunks over TCP. ... ok Testing recvfrom() in chunks over TCP. ... ERROR Testing large receive over TCP. ... ok Testing large recvfrom() over TCP. ... ERROR Testing sendall() with a 2048 byte string over TCP. ... ok Testing shutdown(). ... ok Testing recvfrom() over UDP. ... ok Testing sendto() and Recv() over UDP. ... ok Testing non-blocking accept. ... FAIL Testing non-blocking connect. ... ok Testing non-blocking recv. ... FAIL Testing whether set blocking works. ... ok Performing file readline test. ... ok Performing small file read test. ... ok Performing unbuffered file read test. ... ok ====================================================================== ERROR: Testing recvfrom() in chunks over TCP. ---------------------------------------------------------------------- Traceback (most recent call last): File "./Lib/test/test_socket.py", line 359, in testOverFlowRecvFrom hostname, port = addr TypeError: unpack non-sequence ====================================================================== ERROR: Testing large recvfrom() over TCP. ---------------------------------------------------------------------- Traceback (most recent call last): File "./Lib/test/test_socket.py", line 347, in testRecvFrom hostname, port = addr TypeError: unpack non-sequence ====================================================================== FAIL: Testing non-blocking accept. ---------------------------------------------------------------------- Traceback (most recent call last): File "./Lib/test/test_socket.py", line 451, in testAccept self.fail("Error trying to do non-blocking accept.") File "/home/andymac/cvs/python/python-cvs/Lib/unittest.py", line 254, in fail raise self.failureException, msg AssertionError: Error trying to do non-blocking accept. ====================================================================== FAIL: Testing non-blocking recv. ---------------------------------------------------------------------- Traceback (most recent call last): File "./Lib/test/test_socket.py", line 478, in testRecv self.fail("Error trying to do non-blocking recv.") File "/home/andymac/cvs/python/python-cvs/Lib/unittest.py", line 254, in fail raise self.failureException, msg AssertionError: Error trying to do non-blocking recv. ---------------------------------------------------------------------- Ran 26 tests in 0.330s FAILED (failures=2, errors=2) test test_socket failed -- errors occurred; run in verbose mode for details 1 test failed: test_socket
Below is the output of test_socket with the -v option, from a CVS tree of about 1915 UTC June 18. FreeBSD 4.4, gcc 2.95.3 (-g -O3).
In speaking up now, I'm making the assumption that the non-blocking socket changes should be complete, modulo bugfixes. If this is not the case, please let me know, and I'll wait for the situation to stabilise.
This is supposed to work, there's a missing feature but it's not being tested yet. :-)
Otherwise, is there any more info I can (attempt to) provide? I tried "print"ing the addr variable when running the test, and just get "ERROR" (sans quotes of course).
Try print "\n" + repr(addr) There are probably some differences in the socket semantics. I'd appreciate it if you could provide a patch or at least a clue! (I'll be away from Friday through July 8.) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, 19 Jun 2002, Guido van Rossum wrote:
There are probably some differences in the socket semantics. I'd appreciate it if you could provide a patch or at least a clue!
I've not read enough Stevens to grok sockets code (yet) :-( However, I hope that the instrumented verbose output of test_socket might give you a clue.... I've attached the diff from the version of test_socket (vs recent CVS) that I used, as well as output from test_socket on FreeBSD 4.4 and OS/2+EMX. Getting the FreeBSD issues sorted is a higher priority for me than getting OS/2+EMX working (though that would be nice too). Please let me know if there's more testing/debugging I can do. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370 andymac@pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
There are probably some differences in the socket semantics. I'd appreciate it if you could provide a patch or at least a clue!
I've not read enough Stevens to grok sockets code (yet) :-(
However, I hope that the instrumented verbose output of test_socket might give you a clue....
I've attached the diff from the version of test_socket (vs recent CVS) that I used, as well as output from test_socket on FreeBSD 4.4 and OS/2+EMX. Getting the FreeBSD issues sorted is a higher priority for me than getting OS/2+EMX working (though that would be nice too).
Please let me know if there's more testing/debugging I can do.
I've got some time for this now. Ignoring your OS/2+EMX output and focusing on the FreeBSD logs, I notice: [...]
Testing recvfrom() in chunks over TCP. ... seg1='Michael Gilfix was he', addr='None' seg2='re ', addr='None' ERROR
Hm. This looks like recvfrom() on a TCP stream doesn't return an address; not entirely unreasonable. I wonder if self.cli_conn.getpeername() returns the expected address; can you check this? Add this after each recvfrom() call. if addr is None: addr = self.cli_conn.getpeername() [...]
Testing large recvfrom() over TCP. ... msg='Michael Gilfix was here ', addr='None' ERROR
Ditto.
Testing non-blocking accept. ... conn=<socket object, fd=8, family=2, type=1, protocol=0> addr=('127.0.0.1', 3144) FAIL
This is different. It seems that the accept() call doesn't time out. But this could be because the client thread connects too fast. Can you add a sleep (e.g. time.sleep(5)) to _testAccept() before the connect() call? [...]
Testing non-blocking recv. ... conn=<socket object, fd=8, family=2, type=1, protocol=0> addr=('127.0.0.1', 3146) FAIL
Similar. Try putting a sleep in _testRecv() between the connect() and the send(). [...] Let me know if you want me to provide specific patches... --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, 18 Jul 2002, Guido van Rossum wrote: {...}
Testing recvfrom() in chunks over TCP. ... seg1='Michael Gilfix was he', addr='None' seg2='re ', addr='None' ERROR
Hm. This looks like recvfrom() on a TCP stream doesn't return an address; not entirely unreasonable. I wonder if self.cli_conn.getpeername() returns the expected address; can you check this? Add this after each recvfrom() call.
if addr is None: addr = self.cli_conn.getpeername()
This appears to have the effect you desired. See the attached log. {...}
Testing non-blocking accept. ... conn=<socket object, fd=8, family=2, type=1, protocol=0> addr=('127.0.0.1', 3144) FAIL
This is different. It seems that the accept() call doesn't time out. But this could be because the client thread connects too fast. Can you add a sleep (e.g. time.sleep(5)) to _testAccept() before the connect() call?
Likewise. I took the sleep down to 1ms without failure, though that system has HZ=100 so std resolution I expect would be 10ms. I have also attached for info the log of the same modifications on EMX - situation improved, but still a hiccup there. Also attached is the diff I applied to test_socket.py (as of about 1900 UTC 020719). -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370 andymac@pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
On Sat, 20 Jul 2002, Andrew MacIntyre wrote: {...}
Also attached is the diff I applied to test_socket.py (as of about 1900 UTC 020719).
Oops, that timestamp is still a couple of hours in the future. Should have been 1900 UTC 020718. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370 andymac@pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
participants (2)
-
Andrew MacIntyre -
Guido van Rossum