核心转储与 gdb 堆栈跟踪不同步答案

【问题标题】：Core dump not in sync with gdb stack trace核心转储与 gdb 堆栈跟踪不同步
【发布时间】：2010-09-06 10:40:13
【问题描述】：

我有一个程序由于分段错误而崩溃。核心文件生成。

在 gdb 中运行核心会给我以下信息：

适用于 HP Itanium（32 或 64 位）的 HP gdb 6.1 和目标 HP-UX 11iv2 和 11iv3。

核心由`gcpf1fwcApp'生成。
程序以信号 6 终止，已中止。

我使用了命令

线程应用所有bt

当我检查堆栈跟踪时，我在处于等待状态的主线程中遇到错误。

但是，当我在 GDB 中运行相同的程序时，堆栈跟踪中会出现完全不同的错误。这似乎比核心转储更正确。

程序有 31 个线程。

为什么我会有这种差异？

【问题讨论】：

你的程序是多线程的吗？请提供您在 GDB 中使用过的命令。与您比较 GDB 输出的确切位置是什么？您在生产核心的同一台机器上在哪里分析核心？
是的，程序是多线程的。它有 31 个线程。我正在将核心文件产生的回溯与在 gdb 中运行程序产生的回溯进行比较。我使用的唯一命令是“线程应用所有 bt”。我像这样使用 gdb：gdb -c 。是的，它在同一台机器上。

【解决方案1】：

您可能只是在查看错误的线程。

试试thread apply all where，看看其中一个线程是否真的是abort()ing。

在调试实时进程时，GDB 将在线程收到SIGABRT 时停止，因此可能会向您显示相关线程。

在调试内核时（事后分析），GDB 不知道哪个线程是相关的，因此会按照操作系统将它们保存到内核中的顺序向您显示它们。 Linux内核首先保存导致进程死亡的线程，因此Linux上的GDB显示来自内核的相关线程。我猜 HP-UX 不会这样做，因此 GDB 会向您显示一个“随机”线程。

【讨论】：

是的，我使用线程应用所有 bt。首先，它没有向我显示相关线程。其次，相关线程没有任何迹象表明它已经崩溃。它只是显示它处于线程等待状态。没有任何线索表明实际线程实际上已经崩溃。