gdb中未解決的調試符號

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，則系統將崩潰：(即使將錯誤通知了他們之后，我們也必須使用一種解決方法。調用malloc / new時是否要檢查NULL？如果從多個不同的地方調用它可能會很困難，因為我們包裝了new / malloc，所以對我們來說很容易做到。

OP發出更多評論后更新

如果由於內存泄漏而用完了內存，則不應崩潰，但是請嘗試檢查malloc不返回NULL。 您還應該考慮使用此處提到的“內存不足處理程序”。

在同一Cavium平台上，我們遇到了類似的內存損壞問題，很難追蹤（我們無法在使用valgrind的Linux上運行它）。 我們找到了一種在每次執行malloc時檢查內部內存標頭有效性的方法。 這確實減慢了速度，但是最終它使我們能夠找到問題所在。 如果您無權訪問此類文件或linux上的valgrind，則可以考慮“包裝” malloc / new並自行實現。 這將非常復雜，但可能是最壞的情況。

Answer 3

我想說最后三幀沒有有效信息。 猜測：可能是一些從malloc調用的匯編函數（盡管這些框架應該是可讀的）。

但是，由於您確實從同一庫中知道了malloc的地址，因此可以計算該幀中PC的相對差（例如：幀＃2的-1f50）。 使用您的跨工具鏈，並轉至objdump -d libc.so，並檢查malloc處的代碼-區別...