跨不同Linux机器分析core dump：线程与共享库适配问题及解决方案

问题背景 #

• 在本地编译生成可执行文件thedarkmod.x64，并将调试符号拆分至独立的thedarkmod.x64.debug文件
• 有用户运行该程序时在gdb环境下崩溃，通过gdb的generate-core-file命令生成了core dump文件core.1600
• 本地下载该core文件后，执行gdb ./thedarkmod.x64 core.1600打开文件
• 切换不同线程执行bt命令时，无法得到正常的栈回溯结果，仅显示乱码内容

注意：用户本地存有thedarkmod.x64.debug文件，她在保存core dump前执行bt可以看到正常的栈回溯信息。

初始调试遇到的警告 #

本地打开core dump时，gdb输出大量警告信息，包括：

• Unable to find libthread_db matching inferior's thread library, thread debugging will not be available
• warning: .dynamic section for "libXXX.so" is not at the expected address (wrong library or version mismatch?)

经查询相关资料，第一条警告的原因是本地libthread_db.so.1版本与core dump生成环境的版本不一致，导致无法正常调试多线程程序。先后请求用户提供libthread_db.so.1、libpthread.so.0文件，经过多次尝试配置set solib-search-path、set sysroot、set auto-load safe-path和set libthread-db-search-path参数后，警告消失，出现提示"Thread debugging using libthread_db enabled"，但栈回溯结果仍然错误。

最初的疑问 #

1. 是否有方法可以正常分析运行环境差异极大（内核、pthreads、glibc等版本均不同）的Linux机器生成的core dump？是否有相关的详细操作指南？
2. gdb是否存在类似generate-core-file includecode的命令，可以将所有必要的.so共享库嵌入到core文件中，无需额外配置即可在其他机器打开分析？

当时一度认为Linux core dump几乎没有实用价值，因为不可能为每一个收到的core dump单独创建对应的Linux虚拟机环境。

问题解决更新 #

最终已成功获取到正确的栈回溯结果：

• 常见的solib相关配置方案无效，只有set sysroot配置解决了问题
• 本次场景中栈回溯在libc的free函数处中断，gdb无法继续回溯调用栈，大概率是因为大多数系统库都开启了-fomit-frame-pointer编译参数。在确保gdb加载用户机器提供的libc.so.6文件后，问题得到解决。

完整gdb配置命令 #

除bt外所有命令均为必要配置：

# note: all the .so files obtained from user machine must be put into local directory.
#
# most importantly, the following files are necessary:
#   1. libthread_db.so.1 and libpthread.so.0: required for thread debugging.
#   2. other .so files are required if they occur in call stack.
#
# these files must also be renamed exactly as the symlinks
# i.e. libpthread-2.28.so should be renamed to libpthread.so.0

# load executable file
file ./thedarkmod.x64

# force gdb to forget about local system!
# load all .so files using local directory as root
set sysroot .

# drop dump-recorded paths to .so files
# i.e. load ./libpthread.so.0 instead of ./lib/x86_64-linux-gnu/libpthread.so.0
set solib-search-path .
# disable damn security protection
set auto-load safe-path /

# load core dump file
core core.6487

# print stacktrace
bt

内容的提问来源于stack exchange，提问作者stgatilov