Q:

Pthread mutex assertion error

I'm encountering the following error at unpredictable times in a linux-based (arm) communications application:
pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

Google turns up a lot of references to that error, but little information that seems relevant to my situation.  I was wondering if anyone can give me some ideas about how to troubleshoot this error.  Does anyone know of a common cause for this assertion?
Thanks in advance.

A:

Rock solid for 4 days straight.  I'm declaring victory on this one.  The answer is "stupid user error" (see comments above).  A mutex should only be unlocked by the thread that locked it.  Thanks for bearing with me.

A:

TLDR: Make sure you are not locking a mutex that has been destroyed / hasn't been initialized.
Although the OP has his answer, I thought I would share my issue in case anyone else has the same problem I did.
Notice that the assertion is in __pthread_mutex_lock and not in the unlock. This, to me, suggests that most other people having this issue are not unlocking a mutex in a different thread than the one that locked it; they are just locking a mutex that has been destroyed.
For me, I had a class (Let's call it Foo) that registered a static callback function with some other class (Let's call it Bar). The callback was being passed a reference to Foo and would occasionally lock/unlock a mutex that was a member of Foo. 
This problem occurred after the Foo instance was destroyed while the Bar instance was still using the callback. The callback was being passed a reference to an object that no longer existed and, therefore, was calling __pthread_mutex_lock on garbage memory.
Note, I was using C++11's std::mutex and std::lock_guard<std::mutex>, but, since I was on Linux, the problem was exactly the same.

A:

I was faced with the same problem and google sent me here. The problem with my program was that in some situations I was not initializing the mutex before locking it.
Although the statement in the accepted answer is legitimate, I think it is not the cause of this failed assertion. Because the error is reported on pthread_mutex_lock (and not unlock).
Also, as always, it is more likely that the error is in the programmers source code rather than the compiler.

