Re: HP/UX 11 test_socket failure

Guido van Rossum <[email protected]> Fri, 18 Oct 2002 20:06:34 -0400
Newsgroups gmane.comp.python.snake-farm.user
Message-ID <[email protected]>
> test test_socket failed -- Traceback (most recent call last):
>   File "/mp/slaskdisk/tmp/xenofarm/python/taylor.lysator.liu.se/buildtmp/dist/python/dist/src/Lib/test/test_socket.py", line 495, in testRecv
>     self.fail("Error trying to do non-blocking recv.")
>   File "/mp/slaskdisk/tmp/xenofarm/python/taylor.lysator.liu.se/buildtmp/dist/python/dist/src/Lib/unittest.py", line 260, in fail
>     raise self.failureException, msg
> AssertionError: Error trying to do non-blocking recv.
> 
> .. was due to some timeout being too short. I can't seem to find your
> comment.
> 
> Anyway, this is the relevant failing code:
> 
>     def testRecv(self):
>         # Testing non-blocking recv
>         conn, addr = self.serv.accept()
>         conn.setblocking(0)
>         try:
>             msg = conn.recv(len(MSG))
>         except socket.error:
>             pass
>         else:
> 495>        self.fail("Error trying to do non-blocking recv.")
>         read, write, err = select.select([conn], [], [])
>         if conn in read:
>             msg = conn.recv(len(MSG))
>             self.assertEqual(msg, MSG)
>         else:
>             self.fail("Error during select call to non-blocking socket.")
> 
>     def _testRecv(self):
>         self.cli.connect((HOST, PORT))
>         time.sleep(0.1)
>         self.cli.send(MSG)
> 
> If I understand the test correctly, it is first trying to read from
> the newly accepted socket, which should fail with a socket.error, as
> there is no data to be read yet (the client sleeps and no select call
> yet). However, it seems there is no exception being raised; adding a:
> 
>     except:
>         self.fail("gazonk")
> 
> isn't triggered. Lengthening the client sleep statement to one second
> doesn't help, either. It seems msg is a zero length string:
> 
>     if (type(msg) == types.StringType): print "foo"
> 
> ... gives foo.

Did you try to print `msg`?  Is it indeed zero length?

> Does this mean that some underlying system call returns something
> unexpected on HP/UX?

Sounds like it does, yes.  How annoying. :-(

> Find out in the next installment of the
> mystery of the non-blocking socket; part 2: HP/UX socket API. (I gotta
> go away for a day and will be back sunday).

I'll be gone for a week; back Monday the 27th.

--Guido van Rossum (home page: http://www.python.org/~guido/)