[zeromq-dev] rc == 0 (./zmq/mutex.hpp:94)

Aamir M aamirjvm at gmail.com
Mon Jul 13 17:48:27 CEST 2009


I think I've narrowed down the cause of the error to one specific
messaging mechanism in our application ...

I have a process-scope exchange and two threads with local-scope
queues receiving messages from the exchange. We started seeing the
error when we changed the process-scope exchange from load-balancing
style to data-distribution style. The error seems to go away if we we
turn off the receiver threads or switch it back to load-balancing.

Thanks,
Aamir

On Mon, Jul 13, 2009 at 11:32 AM, Martin Hurton<hurtonm at gmail.com> wrote:
> Hi Aamir,
>
> Please apply the attached patch to 0.6.1 tree and let us know what's
> printed when the assertion fails.
>
> Regards,
> Martin
>
> On Mon, Jul 13, 2009 at 4:36 PM, Aamir M<aamirjvm at gmail.com> wrote:
>> Hello,
>>
>> We have a somewhat large/complex multi-threaded program that makes
>> heavy use of 0MQ for both process-scope and network-scope messaging.
>> Recently we implemented some changes and started seeing the following
>> error:
>>
>> Success
>> rc == 0 (./zmq/mutex.hpp:94)
>> Aborted
>>
>> 0MQ is asserting on ./zmq/mutex.hpp:94 and aborting the program.
>> Before the 0MQ assert occurs, some other function is causing the word
>> "Success" to be printed onto the screen.
>>
>> What could be causing this problem? It is proving very difficult to
>> debug this error because I have no idea which line triggers the
>> problem. Like any other bug related to a multi-threaded race
>> condition, the difficultly is compounded by the fact that the error
>> only occurs SOME of the time (i.e. it cannot be deterministically
>> reproduced).
>>
>> Does anyone have any ideas on how to isolate the offending code? When
>> does 0MQ use this pthread mutex and how could this assert happen while
>> sending / receiving messages?
>>
>> We have been careful to make sure that threads never share the same
>> zmq_api object ... each thread has its own instance of zmq_api, so I
>> don't think this could be the problem.
>>
>> Thanks,
>> Aamir
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>



More information about the zeromq-dev mailing list