如何通过 glibc/malloc 回溯调试崩溃的 Linux 程序（无可用内核）？

Question

我有一个在远程服务器上运行的 C++ 应用程序。我最近介绍了很多新代码。由于担心崩溃，我设置了ulimit -c unlimited，一段时间后我遇到了崩溃，带有一个核心转储，它帮助我调试了一个问题。出于商业原因，正在运行的二进制文件没有调试符号，但我的 PC 上确实有 with-symbols 二进制文件，因此调试很容易。

今天更新的服务再次崩溃，不幸的是这次它没有产生核心转储（旧的core 文件仍然存在，未受影响，我想这可能是某种预期的行为）。这次崩溃发生在 realloc() 内部，所以它向我展示了这个到 stdout 的堆栈跟踪：

*** 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)

如上所说，core文件与上次crash没有变化，所以不能使用。

我想知道是否可以使用此堆栈跟踪来手动找出哪个函数触发了破坏一切的 realloc()。我使用提到的地址尝试了addr2line，但我觉得它把我送到了错误的地方，因为它们完全不相关。可能我应该以某种我不理解并且在谷歌搜索后无法找到的方式使用内存映射。是否有使用此类堆栈跟踪的指南？

Answer 1

objdump - 来自 GNU 工具链的一个很酷的程序，它可以显示有关二进制文件的信息。链接库、内存对齐、函数表等等。

常用：
objdump -T <file>

还有一些工具可以帮助您。比如nm 或readelf（用于elf 文件）。

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