[zeromq-dev] Assertion failure in mailbox.cpp

Jon Gjengset jon at thesquareplanet.com
Tue May 20 11:34:23 CEST 2014

> Your design is correct afaics, it's very much what we do in CZMQ apps
> and I've not seen that crash. A global context, and sockets per thread
> is fine.
> Best would be a repeatable test case to diagnose this.

I'll keep working on that. Not being able to create a test case is what
prevents me from ruling out a bug in my code. However, I did try
replacing ØMQ with nanomsg, leaving the application structure identical
and just replacing zmq_ calls with the nn_ equivalents, and then
everything works correctly. How much we can deduce from that I'm not
sure though.

> Otherwise, you're going to have to hunt down the issue by adding
> tracing into the code, starting where it's asserting. E.g. in
> signaler.cpp, what's the value of dummy when it asserts?

That's what I'm in the process of doing now.
When the signaler.cpp assertion fails, dummy seems to always be 33 :/

In mailbox.cpp, ok is obviously just false because ypipe::recv returns
false. Digging back from there, the error seems to be caused by r being
NULL in ypipe::check_read on line 144. There is a comment above the
check saying:

	//  If there are no elements prefetched, exit.
	//  During pipe's lifetime r should never be NULL, however,
	//  it can happen during pipe shutdown when items
	//  are being deallocated.

I'm not sure why it would only be NULL sometimes though. If this is
expected behavior, then the assert(ok) may be wrong given that
check_read(), and thus read() can actually return false.


More information about the zeromq-dev mailing list