Question

我在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

Answer 1

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

Answer 2

考虑到评论中的额外信息，有以下几点需要检查：

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

可能是堆栈被某种程度上损坏了吗？虽然如果是这种情况，我认为所有的框架都会腐败。你是否有可能使用像Valgrind这样的东西来查看你在某个地方踩踏的记忆？或者至少在Linux上运行应用程序？

在继续前进之前，你真的需要了解前三帧吗？不知道它在malloc中崩溃了吗？也许你应该考虑什么可能导致malloc崩溃。在前面提到的同一个Cavium平台中，我们遇到了一个问题，如果我们在没有内存的情况下调用malloc / new时系统会崩溃:(即使在通知他们这个bug之后，我们也不得不使用hacky work-around。你在调用malloc / new时是否检查NULL？如果你从几个不同的地方调用它可能会很困难。我们有新的/ malloc包装，所以这对我们来说很容易。

来自OP的更多评论后更新

如果由于内存泄漏导致内存耗尽，它应该崩溃，但是尝试检查malloc是否返回NULL。您还应该考虑使用here所述的“内存不足处理程序”。

在同一个Cavium平台上，我们遇到了类似的内存损坏问题，很难追查（我们无法在带有valgrind的Linux上运行它）。我们找到了一种方法来检查每次执行malloc时内部内存头的有效性。这真的减慢了它，但最终它让我们找到了问题。如果你没有访问类似这样的东西，或者在linux上访问valgrind，你可以考虑“包装”malloc / new并自己实现它。这将是相当复杂的，但可能是最糟糕的情况。

Answer 3

我会说最后三帧在某种程度上没有有效信息。猜测：可能是从malloc调用的一些汇编函数（虽然这些框架应该是可读的）。

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

gdb中未解决的调试符号

3 个答案: