From: Charlie G. <cha...@gm...> - 2007-07-24 08:44:50
|
On 7/23/07, Alan Kennedy <jyt...@xh...> wrote: > [Charlie] > > In any case, I'm not expert enough in socket or select to have any > > idea what's going wrong without further investigation. I've attached > > their output in case someone else wants to take a look. From the > > buildbot, it looks like they're ok on Windows, but I'm not sure about > > Linux since that slave is down. I'm going to start digging into these > > in earnest tomorrow night since this is the only thing holding back > > rc3. > > > Looking at test_socket: both of the failures are tests that I introduced. > > 1. testTCPClientTimeout was introduced to test timeouts on client > connects. The test tries to connect to a port (in a client thread), but > the server (in the other thread), while it has bound and opened the > socket, is not accepting new connections. Which should cause the client > connect to timeout and generate a socket.timeout exception. Strange that > it generates "connection refused" instead; this indicates that the > server thread has completely failed to bind to the socket. I may be totally misunderstanding how the test was supposed to work, but I don't think it was doing this. Since testTCPClientTimeout just returned immediately, __tearDown was called by ThreadedTest as soon as it returned which closed the server socket. My Mac is dual-core, and the buildbot Mac has dual G5s, so they would both see the server socket closed before the client socket timeout expired. I committed a change to testTCPClientTimeout that I think fixes this. It just waits for the client thread to call done.set before returning and closing the server socket. However, the test still fails with this change, just with a different error. Now there's no exception thrown at all, Mac or PC, single or dual processor. If I've managed to understand the way the inheritance and calls map through ThreadedTCPSocketTest into TCPClientTimeoutTest, the test code is really running the following: import socket serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) serv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) serv.bind(('localhost', 50007)) serv.listen(1) cli = socket.socket(socket.AF_INET, socket.SOCK_STREAM) cli.settimeout(0.1) cli.connect(('localhost', 50007)) This doesn't cause an exception on cli.connect under CPython or Jython. > 2. testBindException tries to bind to the same address twice, to check > that an address in use exception results. But only the second bind > should fail, because the first bind should already have bound the > address. But the first bind is failing, which indicates the address is > bound before testBindException even starts. Perhaps this is an issue > with reuseaddress? It looks like if a previous test doesn't close its socket bound to the port and address we use in the tests, the bind fails in testBindException. I was able to get testBindException to pass when just the TestJythonExceptions class tests are run by themselves by adding a setUp/tearDown to make sure the socket is closed every time, but it still fails when run with the other tests. I guess one of them is leaving the socket as well and it causes the failure. Maybe that's what you mean by reuseaddress? That's all the time I have to look at this tonight though. More tomorrow! Charlie |