我正在尝试调试一个非常罕见的死锁，并且我已将其范围缩小到 pthread_mutex 的问题，它是类型 1（递归）。我想追踪这个互斥锁的来源，因为我们所有的代码都使用普通的互斥锁，我认为检测互斥锁类型 == 何时递归以追溯它是有意义的。
我尝试在 pthread_mutex_lock 中设置手动断点，通过堆栈指针取消引用 pthread_mutex_t 等以检查其类型，但这被称为数百万次，并且需要永远捕捉互斥类型 == 递归的情况。
我还尝试插入一个库并替换 pthread_mutex_lock 以使在互斥锁类型上设置断点成为可能，但这没有得到任何命中（不相信这是捕获所有对 pthread_mutex_lock 的调用）
我觉得gdb中必须有一种方法可以为每当使用递归类型的互斥锁调用pthread_mutex_lock时设置观察点/条件断点？
对上述任何帮助将不胜感激。提前致谢。
我已将其缩小到 pthread_mutex 的问题，它是类型 1（递归）......
我想追踪这个互斥锁的来源，因为我们所有的代码都使用普通的互斥锁
大概您已经以某种方式确定您的线程在pthread_mutex_lock尝试锁定递归互斥锁时被阻塞，并且您不知道谁持有这个互斥锁，以及为什么。
导致的堆栈跟踪应该准确地pthread_mutex_lock告诉您哪些代码正在尝试锁定该互斥锁，这是您理解问题所需要知道的全部内容。
我不明白您为什么要在锁定该互斥锁的行为中“捕获” pthread_mutex_lock，因为在检测到死锁后查看堆栈可能不会为您提供更多信息。
一般来说，尝试用 GDB 调试互斥锁问题是徒劳的——设置断点（甚至只是附加 GDB）的行为会在一定程度上改变操作的时间，以至于在 GDB 下运行时大多数问题都不会出现。
你可以试试：
(gdb) conditional yourbreakpointid mutex.__m_kind==PTHREAD_MUTEX_RECURSIVE
mutex作用域中互斥锁的名称和yourbreakpointid您在函数中放置的断点的 id在哪里。
__m_kind 可能会根据实现更改名称，如果这个不起作用，请搜索您的分发标头 (pthread.h)。
您可以使用观察点代替gdb断点