GDB 在事后分析中显示了错误的线索

Question

我遇到了 GDB 的奇怪行为。当运行从 C++ 中大量多线程应用程序转储的内核的事后分析时，调试器命令

bt
where
thread info

永远不要告诉我程序实际崩溃的线程。它一直向我显示线程编号 1。因为我习惯于从其他系统看到这个工作，我很好奇这是否是 GDB 中的错误，或者他们是否以某种方式改变了行为。任何人都可以指出我的解决方案，搜索 75 个线程是 PITA，只是为了找出调试器已经知道的东西。

顺便说一下，我在 Debian Squeeze (6.0.1) 上，GDB 的版本是 7.0.1-debian，系统是 x86 并且完全是 32 位。在我较旧的 Debian (5.x) 安装中，调试由完全相同的源转储的核心，为我提供了正确线程的回溯，就像 Ubuntu 10.04 安装上的 GDB 一样。

谢谢！

Answer 1

GDB 不知道是哪个线程导致了崩溃，只是简单地显示了它在core.

Linux 内核通常首先转储有故障的线程，这就是为什么在大多数系统上，一旦您加载core到 GDB 中，您就会以完全正确的线程结束。

我从未见过内核损坏，但我也从未使用过 Debian 6。

我的猜测是它被破坏了，然后得到了修复，Debian 6 附带了一个损坏的内核。

您可以尝试升级 Debian 6 机器上的内核以匹配例如您的 Ubuntu 10.04，然后查看问题是否消失。

或者，Google 用户空间coredumper可以正确执行此操作。您可以链接它，并从 SIGSEGV 处理程序调用它。