Assertion failure caused by too many sockets
Description
Environment
Win7 (32-bit) MSVC10, Gentoo 3.8.13 GCC 4.6.3
Activity
Show:
PieterP November 9, 2013 at 8:54 AM
Fixed on master and backported to 4.0.x for next stable release.
PieterP November 7, 2013 at 2:07 PM
I've put your test case in the issues repository: https://github.com/zeromq/issues/blob/master/574/issue.c
PieterP November 7, 2013 at 2:01 PM
I've pushed a patch, https://github.com/zeromq/libzmq/pull/740
Waiting for review.
Martijn Jasperse November 4, 2013 at 3:41 AM
Has also been tested with pyzmq in multiple environments (gentoo, ubuntu, win7). The following minimal py script shows the behaviour
On pyzmq2.2.0/zmq2.2.0 this raises an exception as expected (zmq.core.error.ZMQError: Too many open files), but on pyzmq13.1.0/zmq3.2.3 an abort is triggered and the host process killed exactly as in the C-code example above. I conclude this is an issue with libzmq3 that was not a problem in libzmq2
I was stress-testing a my language bindings (LabVIEW) and came across an assertion failure if too many sockets are created, as demonstrated by the below test-program
The behaviour of this code depends on OS - I have tested on Win7 (32-bit) and Gentoo (3.8.13/32-bit) both with zmq v3.2.4
On Win7 machine, the code executes properly for N<1024, has an assertion failure for N=1024, and returns EMFILE for N>1024, then assertion fails at the context destroy. The assertion failure is
On Gentoo the critical number is more like 1016 (varies), but the assertion failure occurs at zmq_socket:
It seems like something is not quite right with handling too many sockets; I would expect a return code like EMFILE not assertion failure if a user errs and too many sockets get created.
Obviously creating this many sockets is not "normal operation", but it has arisen in a debugging situation, and the assertion failure occurring on ctx_destroy on Win7 caused some confusion.