如何通過 glibc/malloc 回溯（無可用內核）調試崩潰的 Linux 程序？

Question

我有一個在遠程服務器上運行的 C++ 應用程序。 我最近引入了很多新代碼。 由於擔心崩潰，我設置了ulimit -c unlimited ，一段時間后我崩潰了，有一個核心轉儲，這幫助我調試了一個問題。 出於商業原因，正在運行的二進制文件沒有調試符號，但我的 PC 上確實有帶符號的二進制文件，因此調試很容易。

今天更新后的服務又崩潰了，可惜這次沒有產生coredump（舊的core文件還在那里，原封不動，我猜這可能是某種預期的行為）。 這次崩潰是在 realloc() 內部，所以它向我展示了這個堆棧跟蹤到標准輸出：

*** Error in `./MyApp': corrupted double-linked list: 0x0000000003a04940 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f05ed2897e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x7e6ed)[0x7f05ed2906ed]
/lib/x86_64-linux-gnu/libc.so.6(+0x81cde)[0x7f05ed293cde]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f05ed296184]
/lib/x86_64-linux-gnu/libc.so.6(realloc+0x358)[0x7f05ed296a18]
./MyApp[0x453f58]
./MyApp[0x454a42]
./MyApp[0x457cd6]
./MyApp[0x45eb19]
./MyApp[0x49cfd7]
./MyApp[0x49707b]
./MyApp[0x70734e]
...
a lot more lines
...
./MyApp[0x664c65]
./MyApp[0x73e7b2]
./MyApp[0x70d849]
./MyApp[0x783af4]
./MyApp[0x425da8]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f05ed232830]
./MyApp[0x43a0c9]
======= Memory map: ========
...
< a huge table of memory mappings, ending with: >
Aborted (core dumped)

如上所述，核心文件與之前的崩潰相比沒有變化，因此無法使用。

我想知道我是否可以使用這個堆棧跟蹤來手動找出哪個函數觸發了破壞一切的 realloc() 。 我使用提到的地址嘗試了addr2line ，但我覺得它把我送到了錯誤的地方，因為它們完全無關。 可能我應該以某種我不理解的方式使用內存映射，並且在谷歌搜索后無法找到。 是否有使用此類堆棧跟蹤的指南？

Answer 1

objdump - 來自 GNU 工具鏈的一個很酷的程序，可以向您顯示有關二進制文件的信息。 鏈接庫、內存對齊、函數表等等。

常見用途：
objdump -T <file>

還有一些工具可以幫助您。 像nm或readelf （用於 elf 文件）。

nm -g -C <file>
readelf -sW <file>