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

[Aamir M]

Hi Martin,

I applied the patch of 0MQ 1.0.0 (just released) ... This the output:

pthrad_mutex_lock failed; rc=22
Invalid argument (./zmq/mutex.hpp:99)
Aborted

The invalid argument message occurs on "posix_assert (rc);" in the
following patched function:

        inline void lock ()
        {
            int rc = pthread_mutex_lock (&mutex);
            if (rc)
            {
                fprintf(stderr, "pthrad_mutex_lock failed; rc=%d\n", rc);
                posix_assert (rc);
            }
        }


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