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

Question

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

bt
where
thread info

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

顺便说一句，我使用的是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 处理程序调用它。