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.
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.
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.
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.
In case you are using C++ and std::unique_lock, check this answer: https://stackoverflow.com/a/9240466/9057530
The quick bit of Googling I've done often blames this on a compiler mis-optimization. A decent summation is here. It might be worth looking at the assembly output to see if gcc is producing the right code.
Either that or you are managing to stomp on the memory used by the pthread library... those sort of problems are rather tricky to find.
I have just fought my way through this one and thought it might help others. In my case the issue occured in a very simple method that locked the mutex, checked a shared variable and then returned. The method is an override of the base class which creates a worker thread.
The problem in this instance was that the base class was creating the thread in the constructor. The thread then started executing and the derived classes implementation of the method was called. Unfortunately the derived class had not yet completed constructing and the mutex in the derived class had uninitialised data as the mutex owner. This made it look like it was actually locked when it wasn't.
The solution is really simple. Add a protected method to the base class called StartThread(). This needs to be called in the derived classes constructor, not from the base class.
