massif峰值内存位置在massif.out.*文件中mem_heap_b达峰时的stack段，需用-g编译、禁优化，并通过ms_print定位100%峰值快照及其栈帧，再用addr2line解析地址得源码行号。
Massif 输出里怎么看峰值内存在哪一行
Massif 本身不直接显示源码行号，它只记录堆内存分配的调用栈快照（snapshot），关键在 massif.out.* 文件里的 mem_heap_B 峰值时刻对应的 stack 段。你需要结合编译时的调试信息和 ms_print 工具反查。
实操前提是：程序必须用 -g 编译，且没 strip 符号；最好关掉编译器优化（-O0），否则内联或寄存器分配会让调用栈失真。
- 运行命令要加
--detailed-freq=1（每条分配都记栈）或至少--time-unit=B配合高采样频率，不然可能错过峰值点 -
ms_print massif.out.12345输出中找到->标记的 peak snapshot（通常标着percent = 100.00%） - 往下翻看该 snapshot 的
stack区域，最顶层（第 1 行）是 malloc/new 调用点，往下是调用链 —— 真正“占内存”的代码往往在倒数第二、三层（比如某个循环里反复 new 的容器）
为什么 ms_print 显示的函数名是 ???
这是符号缺失的典型表现，不是 Massif 坏了，而是调试信息没被读到。常见原因有三个：
- 可执行文件被 strip 过：
file ./a.out如果输出含stripped，就彻底没戏，重编译加-g - 链接时用了
-Wl,--strip-all或类似 flag，删掉了 .debug_* 段 - 程序是动态链接的，而
libxxx.so没装对应的debuginfo包（如 CentOS 的glibc-debuginfo）；此时ms_print对系统库显示???属正常，重点盯自己代码里的栈帧
怎么把 Massif 的 stack trace 和源码行号对上
靠 addr2line 手动解析地址是最稳的方式，尤其当 ms_print 不给力时。从 peak snapshot 的 stack 段复制地址（形如 0x40123A），然后：
addr2line -e ./a.out -f -C 0x40123A
注意点：
-
-f显示函数名，-C解析 C++ 符号（避免显示 _ZStlsI... 这种） - 地址必须是未被 ASLR 干扰的 —— 运行 Valgrind 时加
--addr2line-symtab=yes（新版默认开），否则addr2line可能错位 - 如果看到地址落在
operator new里，别停在这儿，往上翻栈帧找你自己的调用者 —— 内存是你的代码申请的，不是 new 本身占的
用 --alloc-fn 抓特定类的内存分配
如果你怀疑是某个自定义容器（比如 MyBuffer::resize()）或封装函数（如 safe_malloc()）导致暴涨，Massif 支持显式标记这些函数为“分配入口”：
valgrind --tool=massif --alloc-fn=MyBuffer::resize --alloc-fn=safe_malloc ./a.out
这样 Massif 会把调用链截断在这些函数，让统计聚焦在业务层，而不是陷在 STL 或 libc 的底层 malloc 里。但要注意：
- 函数名必须和符号表里完全一致（C++ 注意 name mangling，可用
nm -C ./a.out | grep resize确认） - 一个
--alloc-fn只能跟一个函数；多个要用多次--alloc-fn - 它不改变实际内存占用，只是改变调用栈聚合方式 —— 峰值还是那个峰值，但归属更清晰
真正难的不是找到哪一行，而是判断那行代码是否“合理”：一次分配 100MB 可能正常，一小时内重复分配释放 1000 次就值得查泄漏或缓存策略。Massif 给的是证据链，不是结论。
