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.

回答1:

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.

回答2:

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.

回答3:

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.

回答4:

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.

回答5:

I was having same problem

in my case inside the thread i was connecting vertica db with odbc adding following setting to /etc/odbcinst.ini solved my problem. dont geting the exception so far.

[ODBC]
Threading = 1

credits to : hynek

回答6:

adding Threading=0 in /etc/odbcinst.ini file fixed this issue