Created
January 13, 2011 23:59
-
-
Save minrk/778874 to your computer and use it in GitHub Desktop.
stress test script for pyzmq issue 33
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/usr/bin/env python | |
"""Script to connect req/rep pair, close them, then try to send/recv. | |
This should raise ENOTSUP, but sometimes did not in zeromq < 2.0.10.""" | |
import zmq | |
ctx = zmq.Context() | |
def create_bound_pair(ta, tb): | |
a = ctx.socket(ta) | |
b = ctx.socket(tb) | |
iface = 'tcp://127.0.0.1' | |
p = a.bind_to_random_port(iface) | |
b.connect(':'.join([iface,str(p)])) | |
return a,b,p | |
def assertRaisesErrno(errno, f, *args): | |
try: | |
f(*args) | |
except zmq.ZMQError, e: | |
assert e.errno == errno | |
else: | |
raise Exception("Did not raise") | |
def test_close_socket_raises_enotsup(): | |
req, rep, port = create_bound_pair(zmq.PAIR, zmq.PAIR) | |
rep.close() | |
req.close() | |
assertRaisesErrno(zmq.ENOTSUP, rep.recv) | |
assertRaisesErrno(zmq.ENOTSUP, req.send, 'test') | |
if __name__ == '__main__': | |
import sys | |
if len(sys.argv) > 1: | |
N = int(sys.argv[1]) | |
else: | |
N = 1000 | |
for i in range(1,N+1): | |
ten=N/10 | |
if not i%ten: | |
print "%.0f%%: %i"%(100.*i/N, i) | |
test_close_socket_raises_enotsup() |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a stress test for pyzmq Issue 33, where socket.recv/send would not correctly raise ENOTSUP after being closed, and would sometimes crash zeromq. It is a statistical error, so it must be done several times. In zeromq 2.0.6, the error appeared ~10% of the time, by 2.0.9 it was ~0.1% of the time. As of 2.1.0 on Linux, it appears to be resolved, as the runner is now past 1.2M without issue.
However, on OSX (10.6.6, Python 2.6.1, zeromq 2.1.1 HEAD, pyzmq 2.1.1 HEAD as of 01/13/2011), a very small fraction of the time, the following assertion fails:
Possibly related to this: If N is large enough (~10k), this can reliably cause a tcp_lock kernel panic.