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 <report@bugs.python.org>
> <http://bugs.python.org/issue17085>
> _______________________________________