Pthread 互斥断言错误
我在基于 Linux（arm）的通信应用程序中在不可预测的时间遇到以下错误：
pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
Google 发现了很多对该错误的引用，但与我的情况相关的信息很少。 我想知道是否有人可以给我一些关于如何解决此错误的想法。 有谁知道这个断言的常见原因？
提前致谢。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
如果您使用 C++ 和
std::unique_lock，请检查此答案：https://stackoverflow.com /a/9240466/9057530In case you are using C++ and
std::unique_lock, check this answer: https://stackoverflow.com/a/9240466/9057530我所做的快速谷歌搜索经常将此归咎于编译器的错误优化。 一个不错的总结是这里。 可能值得查看汇编输出，看看 gcc 是否生成了正确的代码。
要么是这样，要么你正在设法破坏 pthread 库使用的内存......这类问题很难找到。
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.
遇到了同样的问题
我在使用 odbc 连接 vertica db 的线程内
将以下设置添加到 /etc/odbcinst.ini 解决了我的问题。 到目前为止还没有出现异常。
致谢：hynek
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.
credits to : hynek
我刚刚克服了这个困难，并认为这可能对其他人有帮助。
就我而言，问题发生在一个非常简单的方法中，该方法锁定互斥体，检查共享变量，然后返回。
该方法是对创建工作线程的基类的重写。
此实例中的问题是基类在构造函数中创建线程。 然后线程开始执行并调用该方法的派生类实现。 不幸的是，派生类尚未完成构造，并且派生类中的互斥体作为互斥体所有者具有未初始化的数据。 这使得它看起来像是实际上被锁定了，而实际上并没有被锁定。
解决方案非常简单。 向基类添加一个名为 StartThread() 的受保护方法。 这需要在派生类构造函数中调用，而不是从基类中调用。
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.
在 /etc/odbcinst.ini 文件中添加 Threading=0 修复了此问题
adding Threading=0 in /etc/odbcinst.ini file fixed this issue
连续 4 天坚如磐石。 我宣布这一点的胜利。 答案是“愚蠢的用户错误”（参见上面的评论）。 互斥体只能由锁定它的线程解锁。 谢谢你对我的包容。
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.
TLDR：确保您没有锁定已被销毁/尚未初始化的互斥体。
尽管OP有他的答案，但我想我会分享我的问题，以防其他人遇到与我相同的问题。
请注意，断言位于 __pthread_mutex_lock 中，而不是解锁中。 对我来说，这表明大多数其他遇到此问题的人并没有在与锁定互斥锁的线程不同的线程中解锁互斥锁；而是在不同的线程中解锁互斥锁。 他们只是锁定一个已被破坏的互斥体。
对我来说，我有一个类（我们称之为
Foo），它向其他一些类（我们称之为Bar）注册了一个静态回调函数。 回调传递了对Foo的引用，并且偶尔会锁定/解锁属于Foo成员的互斥体。此问题发生在
Foo实例被销毁而Bar实例仍在使用回调之后。 回调传递了对不再存在的对象的引用，因此在垃圾内存上调用 __pthread_mutex_lock。注意，我使用的是 C++11 的
std::mutex和std::lock_guard，但是，由于我使用的是 Linux，所以问题是一模一样。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_lockand 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 itBar). The callback was being passed a reference toFooand would occasionally lock/unlock a mutex that was a member ofFoo.This problem occurred after the
Fooinstance was destroyed while theBarinstance 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::mutexandstd::lock_guard<std::mutex>, but, since I was on Linux, the problem was exactly the same.我遇到了同样的问题，谷歌将我发送到这里。 我的程序的问题是，在某些情况下，我在锁定互斥锁之前没有初始化它。
虽然接受的答案中的陈述是合法的，但我认为这不是这个失败断言的原因。 因为错误是在
pthread_mutex_lock上报告的（并且不是解锁）。此外，与往常一样，错误更有可能出现在程序员的源代码中，而不是编译器中。
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.