Chuck Remes <cremes.devlist <at> mac.com> writes: > > I need some guidance on how to figure out why I am getting this assertion > (0mq 2.1.11). I assume it is due to > running out of file descriptors, but it's happening in a place (socketpairs) where I thought the code was > eliminated. That is, I didn't think 0mq used socketpairs for internal communication anymore after about > version 2.1.5 or so. > > This is on OSX. I have the open file limit set to 400k. I have modified src/config.hpp MAX_SOCKETS to be > 51200. I get this assertion after opening around 2800 0mq sockets and closing 1500 of them, so I am *nowhere > near* the FD limit or the max socket limit. > > Any suggestions on a printf I could add to the library to help narrow down > the cause of this? > > cr >
What you can do is create a signal handler for SIGABRT and enter infinite loop in there. This will allow you to check number of actually utilized FDs by your process: ls /proc/PID/fd/ | wc -w I'm facing similar problem in the system I'm working with. It seems that dynamic creation and destruction of zmq sockets may lead to triggering of this assertion. What is important is the aggregate number of socket creations and how close they lied in time not the CURRENT amount of zmq sockets. In short: when you close zmq socket it doesn't free its FD immediately. It sheds its ownership of the zmq socket to the reaper thread that eventually will free the FDs. Non-zero lingering period may extend the being-reaped state of the socket. You may want to set the lingering period to 0. regards, Marcin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
