Linux进程崩溃后，如何从核心转储获取已卸载共享库加载地址？

当进程通过dlclose卸载共享库后，其内存通常会被系统回收或复用，核心转储中不会直接保留已卸载库的完整元数据，但可以通过以下几种间接手段尝试还原加载地址：

• 依赖/proc/<pid>/maps的历史快照
  如果在进程崩溃前，你有定时采集过目标进程的/proc/<pid>/maps文件，该文件会记录所有曾加载的共享库的地址范围、路径等信息。将崩溃时的无效回调地址与历史快照中的地址段匹配，就能反向定位到对应的已卸载共享库及其加载基地址。

• 挖掘动态链接器的残留元数据
  动态链接器（ld.so）在加载共享库时会维护link_map结构体链表，记录库的加载地址、路径、符号表等信息。即使执行了dlclose，部分link_map节点可能未被完全清理，残存在进程内存中：

  1. 在gdb中搜索核心转储里的共享库名称字符串，比如：

     find 0x0, 0xffffffff, "libyourlib.so"
     

  2. 找到字符串地址后，根据link_map结构体的布局（l_name字段的偏移固定），向上偏移计算出link_map的起始地址，再读取其中的l_addr字段，即可得到该库的加载基地址。

• 分析崩溃地址的内存属性与区间特征
  通过gdb的info mem命令查看崩溃地址所在内存区域的属性（如是否曾为可执行段），结合Linux系统共享库的常规加载区间（通常在高地址段），缩小可能的库范围。再对比本地同版本共享库的代码段偏移，就能推导该崩溃地址对应的原共享库加载基地址。

• 借助elfutils工具集深度解析
  使用eu-readelf、eu-stack等elfutils工具分析核心转储的ELF结构：

  • 用eu-readelf -l <core-file>查看进程的加载段信息，寻找残留的动态链接相关段；
  • 用eu-nm <core-file>搜索可能残留的符号，关联到已卸载的共享库。

需要注意：这些方法的可靠性依赖于内存未被完全覆盖。如果dlclose后系统立即复用了该内存区域，残留信息会被破坏，此时无法还原已卸载库的加载地址。

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