我遇到了GDB的奇怪行为。当运行对核心的事后分析，从c ++中的大量多线程应用程序转储时，调试器命令
bt
where
thread info
永远不要告诉我程序实际崩溃的线程。它一直向我显示线程编号1.由于我以前看到这个工作来自其他系统，我很好奇是否是GDB中的Bug或者他们是否以某种方式改变了行为。任何人都可以指出我的解决方案，它是PITA搜索75个线程，只是为了找出调试器已经知道的东西。
顺便说一句，我在Debian Squeeze（6.0.1）上，GDB版本是7.0.1-debian，系统是x86，完全是32位。在我较旧的Debian（5.x）安装中，调试核心，由完全相同的源转储，为我提供了正确线程的回溯，就像在Ubuntu 10.04安装上的GDB一样。
谢谢！
答案 0 :(得分：3)
GDB不知道哪个线程导致崩溃，只是显示它在core中看到的第一个线程。
Linux内核通常首先转储故障线程，这就是为什么在大多数系统上，一旦将core加载到GDB中，就会以完全正确的线程结束。
我从来没有见过这个被打破的内核，但我也从未使用过Debian 6.
我的猜测是，它已被破坏，然后得到修复，Debian 6附带了破碎的内核。
您可以尝试升级Debian 6计算机上的内核以匹配例如你的Ubuntu 10.04，看看问题是否消失。
或者，Google用户空间coredumper可以正确执行此操作。您可以将其链接，并从SIGSEGV处理程序中调用它。