时间戳

首页 > 解决方案 > gdb 核心调试 - 如何在回溯中显示 .so 名称

linux - gdb 核心调试 - 如何在回溯中显示 .so 名称

问题描述

我正在尝试使用 gdb 调试大型项目的核心转储。问题是应用程序是一组相当多的共享对象。每个组件也被加密。现在在本地准备整个环境是相当多的工作（可能需要几天时间）。所以我希望当我尝试调试 coredump 时，我至少会在回溯中获得 .so 名称，这样我就可以只获取我真正需要的文件。不幸的是，当我这样做时，我只会得到这样的空结果：

Thread 3 (LWP 4582):
#0  0x00007f11956d6d50 in ?? ()
#1  0x00007f112a810a68 in ?? ()
#2  0x000000002a810ab8 in ?? ()
#3  0x00007f1134001b00 in ?? ()
#4  0x00007f112a810a90 in ?? ()
#5  0x00007f112a810a68 in ?? ()
#6  0x00007f1169d3ba5b in ?? ()
#7  0x000000000163ccd8 in ?? ()
#8  0x0000000000000000 in ?? ()

coredump 甚至不知道导致错误的可执行文件或共享对象的名称是否正确？有什么方法可以获取这些信息吗？

谢谢

标签： linuxgdbshared-librariesbacktrace

解决方案

最可能的原因：

(gdb) info shared No shared libraries loaded at this time

是您正在core从远程机器分析 a ，并且没有正确执行。

特别是，GDB 通过检查加载器中_r_debug变量的内容来知道在崩溃时进程中加载​​了哪些共享库（这并不完全正确，但已经足够接近了）。

GDB_r_debug通过查看local ld-linux找到 的地址，并通过在core.

如果ld-linux崩溃点机器上的ld-linux存在与分析机器上的存在不同，那么 GDB 将有效地查看随机地址，并且无法定位任何共享库。

要正确设置，请使用此答案。至少，您必须提供正确的ld-linux.so. 当您使用它时，还需要复制libc.so.6和libpthread.so.0-- 如果程序被信号终止，则这些都是获得正确堆栈跟踪所必需的。

推荐阅读