如何避免breakpad dmp转换为核心文件时出现错误的符号偏移

Question

当 GDB 从 amd64、i686 和 aarch64 上的 Breakpad 在 Linux 上创建的小型转储中读取使用

minidump-2-core

生成的一些核心文件时，我收到此错误（使用 2024 年 1 月 30 日以及 2021 年的 Breakpad 提交）：

$ gdb /path/to/binary corefile
...
Failed to read a valid object file image from memory.

之后，运行

backtrace

结果只是：

#0  0x00007fd8f28b9113 in ?? ()

当我遇到这样的核心文件时，像

main

这样的符号并不位于主可执行文件映射的区域中，而是看起来像二进制文件的

.text

段的偏移量。但是，如果

print &main

确实返回可执行文件映射区域内的有效地址，则

backtrace

也可以工作。

minidump_stackwalk

工具始终可以正确解析符号。二进制文件包含调试符号。我已经使用 GDB v8.2 到 v14.2 进行了测试。

我可以使用

.text

获取二进制文件的

libc.so.6

文件偏移量（以及

objdump -h

如果需要，具体取决于堆栈上的函数），将其添加到我从

md2core

输出中获得的映射可执行文件偏移量，并使用

add-symbol-file

手动添加符号文件，然后使用

core-file core

重新加载核心。这使得

backtrace

能够正确显示堆栈。在所有情况下，

info proc map

不会打印任何内容，而对于真正的核心文件，它会列出二进制文件、libc 等的区域。另外：

(gdb) info sharedlibrary
No shared libraries loaded at this time.

1. Failed to read a valid object file image from memory

   是提示吗 小型转储不完整并且需要修复？他们是 默认格式（所有线程的堆栈内存）。
2. 如何才能

   minidump-2-core

   生成具有有效映射信息的核心文件，GDB 需要这些信息来解析可执行文件的符号？

Answer 1

刚刚对breakpad存储库进行了修复，似乎可以解决此问题：https://github.com/google/breakpad/commit/417f5dbd0af9f96ca3e5faa99f41c064b89b40fd