[zeromq-dev] rc == 0 (./zmq/mutex.hpp:94)
Martin Hurton
hurtonm at gmail.com
Mon Jul 13 18:14:45 CEST 2009
Hi Aamir,
What OS are you running your application on? And what thread library
are you using?
Regards,
Martin
On Mon, Jul 13, 2009 at 5:48 PM, Aamir M<aamirjvm at gmail.com> wrote:
> 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