mtrace 不适用于动态库地址空间分析，因其仅追踪 malloc/free 等堆分配行为，不感知 mmap、ASLR、段映射等虚拟内存管理机制；分析动态库应使用 /proc/PID/maps、ldd、readelf 等工具组合。
Linux 中的 mtrace 工具本身**不用于分析动态库加载或虚拟地址空间布局**，它专用于追踪 malloc/free 等堆内存分配行为。若想分析动态库（.so）加载对进程虚拟地址空间（VMA, Virtual Memory Areas）的影响，应使用 /proc/PID/maps、ldd、readelf、pmap 等工具组合，而非 mtrace。
为什么 mtrace 不适用于动态库地址空间分析
mtrace 是 GNU libc 提供的堆内存泄漏检测机制：它通过预加载钩子函数拦截 malloc/calloc/realloc/free 调用，并将记录写入日志文件，再由 mtrace 命令解析比对。它完全不感知 mmap（动态库加载依赖此系统调用）、brk、共享库基址、ASLR 偏移或段映射（text/data/bss/rodata）等虚拟内存管理行为。
混淆点常源于“trace”一词——mtrace 的 trace 是内存分配轨迹，不是地址空间映射轨迹。
正确分析动态库对虚拟地址空间占用的方法
动态库通过 mmap(2) 映射到进程地址空间，其布局可见于 /proc/[pid]/maps。关键步骤如下：
-
启动目标进程并获取 PID：运行程序（如
./myapp），用ps aux | grep myapp或pgrep myapp查 PID -
查看完整虚拟内存映射：执行
cat /proc/[PID]/maps，每行代表一个 VMA 区域，字段含义为：
起始地址-结束地址 权限 偏移 设备:inode 文件路径（若为动态库则显示 .so 路径） -
聚焦共享库段：筛选含
.so的行，例如：7f8a2b100000-7f8a2b121000 r-xp 00000000 08:01 123456 /lib/x86_64-linux-gnu/libc.so.6
此行表示 libc 的代码段（r-xp）占约 132 KB（0x21000 字节） -
统计总占用：用
awk计算所有 .so 相关 VMA 的大小总和：awk '/\.so\./ {split($1,a,"-"); sum += strtonum("0x"a[2]) - strtonum("0x"a[1])} END {print sum " bytes"}' /proc/[PID]/maps
辅助定位与验证工具链
单靠 maps 只能看到运行时结果，需结合其他工具理解加载逻辑：
-
ldd ./myapp：列出直接依赖的动态库及其解析路径（不含间接依赖或 dlopen 加载的库） -
readelf -d ./myapp | grep NEEDED：查看 ELF 的 DT_NEEDED 条目，确认编译期声明的依赖 -
pmap -x [PID]：以易读格式汇总内存使用，含“shared libraries”小节，显示各库映射总大小（含多段：text+data+bss） -
strace -e trace=mmap,mprotect,openat ./myapp 2>&1 | grep '\.so'：跟踪运行时实际发生的库文件打开与映射系统调用（尤其对 dlopen 场景有效）
注意 ASLR 和多段映射带来的复杂性
现代 Linux 默认启用 ASLR，每次运行同一进程，动态库加载地址都不同，但 VMA 大小基本稳定（除非库版本升级或链接参数变化）。另外，一个 .so 通常被映射为多个 VMA：
– r-xp 段（代码）
– rw-p 段（数据、GOT/PLT）
– r--p 段（只读数据、.rodata）
– 可能还有 ---p（匿名映射，如 TLS 或 BSS 扩展）
因此统计时应匹配库名（如 libc.so.6）的所有相关行，而非仅第一行。
