Linux gdb回溯和pthread_cond_wait（）

这是在Redhat EL5机器上的，该机器具有2.6.18-164.2.1.EL5 x86_64内核，使用gcc 4.1.2和gdb 7.0

当我使用gdb运行应用程序并在其运行时中断时，我的几个线程在执行回溯跟踪时显示以下调用堆栈：

#0  0x000000000051d7da in pthread_cond_wait ()
#1  0x0000000100000000 in ?? ()
#2  0x0000000000c1c3b0 in ?? ()
#3  0x0000000000c1c448 in ?? ()
#4  0x00000000000007dd in ?? ()
#5  0x000000000051d630 in ?? ()
#6  0x00007fffffffdc90 in ?? ()
#7  0x000000003b1ae84b in ?? ()
#8  0x00007fffffffdd50 in ?? ()
#9  0x0000000000000000 in ?? ()

这是常见问题的症状吗？

---

在等待条件时查看调用堆栈是否存在已知问题？

在我看来，这似乎是一个损坏的堆栈跟踪

例如：

#9  0x0000000000000000 in ?? ()

---

空时不应该有代码。通常，当多个线程共享一个资源时，需要同步。 在这种情况下，当您中断程序时，您将看到只有一个线程正在运行（即访问资源），而其他线程正在

pthread\u cond\u wait（）

中等待

所以我不认为

pthread\u cond\u wait（）

本身有问题

---

如果您的程序因死锁而挂起或性能无法扩展，则可能是由于

pthread\u cond\u wait（）

造成的，问题是

pthread\u cond\u wait

是用手工编码的程序集编写的，并且在构建

glibc

时显然没有适当的展开描述符（x86\u 64上需要展开堆栈）。这个问题最近可能已经解决了

---

您可以尝试构建并安装最新的glibc（注意：如果安装错误，您的机器可能会无法转动；请务必小心操作！），或者只使用

pthread\u cond\u wait

中的“伪”堆栈跟踪，这就是问题所在。我在32位EL5机器上试用了我的应用程序，gdb工作正常。