Linux下minidump_stackwalk与dump_syms模块ID不匹配问题

问题根因 #

• 模块ID不一致的核心原因是MIPS架构下Breakpad的模块ID计算逻辑存在版本差异：
  你通过readelf查到的GNU BUILD ID本身在strip前后是一致的，但不同版本的Breakpad在MIPS平台生成模块ID时，对BUILD ID的端序转换规则、是否追加段标识的逻辑不统一。你当前用来生成符号文件的dump_syms版本，和编译进程序、负责生成minidump的Breakpad客户端版本不匹配，两边算出的模块ID自然对不上。你观察到的dump_syms输出的ID、minidump里记录的ID长度差异，就是版本差导致的逻辑不同。
• 手动修改ID后仍无法回溯栈，是因为你生成符号用的so文件和实际运行时加载的strip后so文件段偏移不匹配：如果strip操作没有保留ELF的program header加载基址、段偏移属性，哪怕BUILD ID一致，符号文件里记录的函数地址和程序运行时的实际PC地址也会完全错位，自然无法正常解析栈。

修复步骤 #

• 第一步：对齐Breakpad工具链版本
  重新编译dump_syms工具，保证它和你集成到业务程序里的Breakpad客户端代码来自完全相同的源码版本，禁止混用系统源安装的dump_syms和自行编译集成到程序中的Breakpad客户端。
  版本对齐后，直接对生产环境部署的、strip后的my_lib.so执行dump_syms操作，查看输出的MODULE行ID，应该和minidump中提示缺失的ID完全一致。
• 第二步：按规范生成符号文件和部署版so
  不要直接用未strip的so生成最终符号，也不要随便用strip参数处理so，正确流程如下：
  1. 编译产出带完整调试信息、未做任何裁剪的my_lib.so，记为my_lib.so.debug
  2. 用对齐版本后的dump_syms处理my_lib.so.debug，生成符号文件my_lib.so.sym
  3. 对my_lib.so.debug执行strip，生成部署用的裁剪版so，必须加参数保留ELF关键属性：

     strip --strip-debug --strip-unneeded --preserve-dates my_lib.so.debug -o my_lib.so
     

  4. 校验两个so文件的一致性：

     # 校验BUILD ID一致
     readelf -n my_lib.so.debug | grep "Build ID"
     readelf -n my_lib.so | grep "Build ID"
     # 校验LOAD段的虚拟地址、偏移完全一致
     readelf -l my_lib.so.debug | grep LOAD
     readelf -l my_lib.so | grep LOAD
     

     以上命令的输出必须完全相同，否则说明strip操作破坏了ELF结构，需要更换对应工具链版本的strip工具重新处理。
• 第三步：正确放置符号文件
  读取my_lib.so.sym第一行MODULE字段中的ID值，按Breakpad要求创建目录结构，禁止手动修改符号文件里的ID值：

  # 示例：如果MODULE行ID为AC40136B433E5A68F66CCE8C2C2E6C250
  mkdir -p ./symbols/my_lib.so/AC40136B433E5A68F66CCE8C2C2E6C250
  cp my_lib.so.sym ./symbols/my_lib.so/AC40136B433E5A68F66CCE8C2C2E6C250/
  

  后续执行minidump_stackwalk时通过-s参数指定上述symbols目录，即可正常解析栈信息。

注意：如果是MIPS64架构，还需要确认编译Breakpad客户端时开启了对应架构的正确宏定义，宏配置错误也会导致ID计算逻辑异常。

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