ddve...@ucar.edu added the comment:
The problem is that test_sendall_interrupted and
test_sendall_interrupted_with_timeout make an assumption which is false
on my hw, namely that it will take a long time for sendall() to
complete. In fact, the following snippet:
from timeit import default_timer
import socket
c,s=socket.socketpair()
start = default_timer()
c.sendall("x" * (1024**2))
end= default_timer()
print end-start
probably fits some cache and runs in well less than 1ms (prints
something between 0.000797 and 0.000876) on the server where this test
is crashing (it takes forever on my laptop). Sending 1024**3 instead
takes forever on the server too and makes the test pass. So the
following patch is the least different for what you have now and it
works on my server:
--- original/Python-2.7.5/Lib/test/test_socket.py 2013-05-11
21:32:47.000000000 -0600
+++ Python-2.7.5/Lib/test/test_socket.py 2013-06-05
11:20:59.390516537 -0600
@@ -685,11 +685,11 @@
c.settimeout(1.5)
with self.assertRaises(ZeroDivisionError):
signal.alarm(1)
- c.sendall(b"x" * (1024**2))
+ c.sendall(b"x" * (1024**3))
if with_timeout:
signal.signal(signal.SIGALRM, ok_handler)
signal.alarm(1)
- self.assertRaises(socket.timeout, c.sendall, b"x" *
(1024**2))
+ self.assertRaises(socket.timeout, c.sendall, b"x" *
(1024**3))
finally:
signal.signal(signal.SIGALRM, old_alarm)
c.close()
However this is just waiting for a failure when a different hw will make
the sendall faster again. I believe two more robust tests should be
designed, without making assumptions about timing. Not sure it's
possible, but it's certainly desirable.
Regards,
Davide Del Vento,
NCAR Computational & Information Services Laboratory
Consulting Services Software Engineer
http://www2.cisl.ucar.edu/uss/csg/
SEA Chair http://sea.ucar.edu/
office: Mesa Lab, Room 55G
office: (303) 497-1233
mobile: (303) 720-6338
On 05/19/2013 07:33 AM, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> ddvento, I'm afraid you'll have to diagnose a bit more by tracing what
> happens during test_sendall_interrupted and
> test_sendall_interrupted_with_timeout. These test cases have a legitimate use
> for arming an alarm signal, but for some reason it seems the signal is
> triggered after those tests finish. Try printing exactly what happens at each
> step in those tests.
>
> Etienne, I'm not sure what the issue specifically is. Is Linux TIPC has a
> memory leak issue, it isn't really Python's problem. If any case, it is a
> separate issue and therefore should be discussed on a separate bug entry.
>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue17085>
> _______________________________________
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17085>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
