epoll::loop triggers "Assertion failed: (msg_->flags | ZMQ_MSG_MASK) == 0xff (zmq.cpp:223)"
Description
Environment
RHEL5 on kernel 2.6.18-194.el5PAE (i386)
Attachments
2
Activity
Show:
Michaël Melchiore September 19, 2012 at 9:23 AM
After investigation, closing the ticket because the bug came from my application.
I am developping a small communication layer, which manages two sets of sockets:
pull sockets monitored by emq_poll for incoming messages
push sockets invoked through application code to send messages
While polled sockets were used in a thread-safe manner, application code could spawn several threads and share push sockets between them... Now that I have redesigned the communication layer to prevent this from happening, the assert is gone.
Ian Barber September 18, 2012 at 6:33 AM
Could you post a minimal code sample that recreates the bug, if it is happening reliably?
The above assertion consistently fails in my software.
From the core dump (see attached logs), the assert ultimately comes from an epoll_t::loop that runs from a worker thread. I suppose this thread is internally spawned by zmq_poll.
I read in the mailing list that this assert typically fails when trying to get the size of an uninitialised invalid or closed message. In my example, I poll three zmq (pull) sockets for incoming messages. Zmq messages are only involved after the zmq_poll call, if necessary.
As advised by the guide, I have checked that the three monitored sockets are created in the same context and handled in the same thread.
Since the problem raises from an internal zmq thread, I do not know where to look next.