c - 当 Linux 在 C 程序中崩溃时获得更好的调试

Question

我们有一个在 MIPs 内核上运行的嵌入式 Linux 内核版本。我们编写的程序运行特定的测试套件。在其中一项压力测试(运行约 12 小时)期间，我们遇到了段错误。这反过来会生成一个核心转储。

不幸的是核心转储不是很有用。崩溃发生在某些动态链接的系统库中(可能是 pthread 或 glibc)。核心转储中的回溯没有帮助，因为它只显示崩溃点而没有其他调用者(我们的用户空间应用程序是使用 -g -O0 构建的，但仍然没有回溯信息):

Cannot access memory at address 0x2aab1004
(gdb) bt
#0  0x2ab05d18 in ?? ()
warning: GDB can't find the start of the function at 0x2ab05d18.

    GDB is unable to find the start of the function at 0x2ab05d18
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x2ab05d18 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.

另一个不幸的是我们不能运行 gdb/gdbserver。 gdb/gdbserver 在 __nptl_create_event 上不断中断。看到测试创建线程、计时器并每 5 秒销毁一次，几乎不可能长时间坐着继续点击它们。

编辑:另外请注意，我们的工具链不支持 backtrace 和 backtrace_symbols。

因此:

1. 有没有办法捕获段错误并生成更多回溯数据、堆栈指针、调用堆栈等？

2. 有没有办法从 .so 文件中崩溃的核心转储中获取更多数据？

谢谢。

Answer 1

GDB can't find the start of the function at 0x2ab05d18

崩溃时那个地址是什么？

执行info shared，并找出是否有包含该地址的图书馆。

您遇到问题的最可能原因是:在将它上传到您的目标之前，您是否运行了 strip libpthread.so.0？不要那样做:GDB 要求 libpthread.so.0 不被剥离。如果您的工具链包含带有调试符号的 libpthread.so.0(因此对于目标而言太大)，请在其上运行 strip -g，而不是完整的 strip 。

更新:

info shared produced Cannot access memory at address 0x2ab05d18

这意味着 GDB 无法访问共享库列表(这将解释缺少的堆栈跟踪)。最常见的原因:实际生成 core 的二进制文件与您提供给 GDB 的二进制文件不匹配。一个不太常见的原因:您的核心转储被截断(可能是由于 ulimit -c 设置得太低)。