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
Assertion failed: fds.size () <= FD_SETSIZE (..\..\..\src\select.cpp:70)
On Gentoo the critical number is more like 1016 (varies), but the assertion failure occurs at zmq_socket:
Too many open files (signaler.cpp:234)
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.
Win7 (32-bit) MSVC10, Gentoo 3.8.13 GCC 4.6.3
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
Fixed on master and backported to 4.0.x for next stable release.