[zeromq-dev] Assertion failure in mailbox.cpp

Jon Gjengset jon at thesquareplanet.com
Tue May 20 13:29:54 CEST 2014


> > 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.

I just tried to comment out all my calls to zmq_close(), and the
assertion in mailbox.cpp still fails. It still only happens after I've
begun the shutdown procedure, even though all this now boils down to is
sending a message with a NULL pointer on the outgoing queue..
When it doesn't crash, the application just hangs when I call
zqm_term(), which is to be expected.

Just to make absolutely sure, sending a pointer this way with ØMQ is
completely legal even if p == NULL, right?

thread1:
	static void *queue_w;
	...
	void *p = ...;
	queue_w = zmq_socket(ctx, ZMQ_PAIR);
	zmq_bind(queue_w, "inproc://q");
	zmq_send(queue_w, &p, sizeof(void *), 0);

thread2:
	static void *queue_r;
	...
	void *p;
	queue_r = zmq_socket(ctx, ZMQ_PAIR);
	zmq_connect(queue_r, "inproc://q");
	zmq_recv(queue_r, &p, sizeof(void *), 0);

And before you say anything, I known sending pointers tightly couples
the design, but unfortunately it is necessary for now..

If that is fine, then I really don't know what is causing the race.
There is *no way* the threads can step on each others' sockets, because
they are declared static and each thread is in its own file, and the
only calls that are being made are send in one thread and recv in
another..

Could there be a race on the message queue inside inproc?



More information about the zeromq-dev mailing list