gdb 中未解析的调试符号答案

【问题标题】：Unresolved debugging symbols in gdbgdb 中未解析的调试符号
【发布时间】：2012-05-23 12:30:49
【问题描述】：

我在 powerpc 平台的 Montavista linux 上运行的一个应用程序崩溃了。前 3 个堆栈帧显示绝对地址而不是符号。我的构建机器托管在不同的平台上，我正在使用交叉编译器来构建应用程序。我怎样才能取回符号。

回溯如下 -

#0  0x0f272adc in ?? () from /lib/libc.so.6
#1  0x0f3537fc in ?? () from /lib/libc.so.6
#2  0x0f274f44 in ?? () from /lib/libc.so.6
#3  0x0f276e94 in malloc () from /lib/libc.so.6
#4  0x105c94a8 in fast_memget (module_id=0, noctets=820, err=0x3893e710) at ../common/src/portlayer.c:1305
#5  0x1055f734 in glbSipParserDecodeMessage (
    message=0x3b225e58 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 10.194.182.55:5060;branch=z9hG4bK2495419925-4086;received=10.194.182.55;ingress-zone=mxenode51\r\nCall-ID: 2469861343-4086\r\nCSeq: 6 INFO\r\nContact: <sip:4084565719@10.194"..., opt=0x3893e70c, messageLength=425, nextmesg=0x3893e898, pContext=0x3893e8cc, ppSipMessage=0x3893e6bc, err=0x3893e710) at src/sipdecode.c:6184

【问题讨论】：

你用-g编译了吗？或优化（-O1、-O2 等）？
布雷迪，我需要检查一下。实际上，我们有大量的应用程序在分布式环境中运行在基于 ATCA 的平台上，因此构建过程是由构建工程师自动化和管理的。如果启用优化会有什么不同。谢谢你的帖子。
哇，听起来很熟悉。我们曾经考虑过 ATCA。我在从 linux 交叉编译到 Cavium Octeon (MIPS) 时遇到了这个问题，并且在使用他们的参考板时特别看到，经过优化编译后我也看不到符号。

标签： c++ gdb cross-compiling

【解决方案1】：

您需要安装带有调试信息的 C 库 (libc)。在 Debian 或衍生系统（例如 Ubuntu）上，它是一个名为 libc6-dbg 的包。

【讨论】：

但 malloc 符号已在堆栈帧 3 中正确解析，它属于同一个库 libc.so.6。

【解决方案2】：

我会说最后三帧不知何故没有有效信息。猜测：可能是一些从 malloc 调用的汇编函数（尽管那些框架应该是可读的）。

但由于您确实知道来自同一个库的 malloc 的地址，因此您可以计算 PC 在该帧中的相对差异（例如：帧 #2 的 -1f50）。使用您的交叉工具链，并使用 objdump -d libc.so，并检查 malloc 中的代码 - 区别...

【讨论】：

【解决方案3】：

考虑到 cmets 中的额外信息，这里有一些事情需要检查：

应用程序是否经过优化（-O1、-O2 等）编译？如果是这样，请在不使用这些选项的情况下重新编译。我自己在 Cavium Octeon (MIPS) 上进行交叉编译时遇到过这种情况，并观察到优化标志的存在导致看到符号时出现问题。

可能是堆栈以某种方式损坏了吗？尽管如果是这种情况，我认为所有帧都会损坏。您是否有可能使用 Valgrind 之类的东西来查看您是否在某处踩踏记忆？或者至少在 Linux 上运行应用程序？

在继续之前，您真的需要了解更多关于前 3 帧的信息吗？知道它在 malloc 中崩溃还不够吗？也许相反，您应该考虑可能导致 malloc 崩溃的原因。在前面提到的同一个 Cavium 平台中，我们遇到了一个问题，如果我们在没有剩余内存的情况下调用 malloc/new，系统会崩溃:(即使在通知他们这个错误之后，我们也不得不使用一个 hacky 解决方法。您在调用 malloc/new 时是否检查 NULL？如果您从多个不同的地方调用它，这可能会很困难。我们已经包装了 new/malloc，所以这对我们来说很容易做到。

在更多来自 OP 的 cmets 后更新

无论是否由于内存泄漏导致内存不足，它都不应该崩溃，但请尝试检查 malloc 是否返回 NULL。您还应该考虑使用here 中提到的“内存不足处理程序”。

在同一个 Cavium 平台上，我们遇到了类似的内存损坏问题，而且很难追踪（我们还不能在使用 valgrind 的 Linux 上运行它）。我们找到了一种方法来检查每次执行 malloc 时内部内存头的有效性。这确实减慢了速度，但最终它让我们找到了问题所在。如果您无法访问类似的东西，或者 linux 上的 valgrind，您可以考虑“包装” malloc/new 并自己实现它。这将非常复杂，但可能是最坏的情况。

【讨论】：

布雷迪，感谢您提供的信息。 1) 堆栈损坏被排除，因为其他堆栈帧在核心转储中清晰可见。 2) malloc 失败的原因可能是我们在进程中存在内存泄漏导致没有可分配的内存，内存损坏导致我们有内存但 malloc 由于内部内存头结构损坏而失败，或者我们有压力测试 5 小时后观察到崩溃，导致内存碎片严重。