> 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.
Jon
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
