massif 默认不分析栈内存，需显式启用--stacks=yes；启用后性能下降3–5倍，且多线程、自定义栈、优化编译等场景下数据易失真，仅适合粗略排查栈使用异常。

Massif 默认不分析栈内存

不能直接看，除非你显式启用。Massif 的 --stacks 选项默认是 no，也就是说它只统计堆（malloc/new 等）分配，完全忽略栈空间。如果你看到报告里没提栈、也没出现 stack 相关字段，就是这个原因在起作用。

启用栈分析必须加 --stacks=yes

要让 Massif 跟踪栈使用，得在命令行中明确打开：

valgrind --tool=massif --stacks=yes ./myapp

注意几点：

Valgrind 3.23.0

Valgrind 3.23.0 官方历史源码发布包，适合旧项目兼容、复现历史内存检测结果、排查版本差异和在受支持 Unix-like 系统上自行构建。

下载

• --stacks=yes 是 Valgrind 参数，必须放在 ./myapp 前面，写在后面会被当成程序参数，无效
• 启用后性能会明显下降——实测通常慢 3–5 倍，高并发或深度递归场景可能更甚
• Massif 假设主线程初始栈大小为 0，以便凸显你代码实际“增长”的部分；但它无法准确识别 signal stack 或某些线程私有栈边界，此时报告的栈值可能偏高或失真
• 输出中会出现 stack 字段，和 heap 并列，ms_print 生成的图表也会包含双曲线

栈分析结果不可靠的常见情况

即使开了 --stacks=yes，以下场景下栈数据也容易误判或缺失：

• 程序用了 sigaltstack() 或 pthread_attr_setstack() 自定义栈，Massif 可能压根没监控到那块内存
• 多线程环境下，Massif 默认只跟踪主线程栈；worker 线程的栈增长不会被计入，除非配合 --pages-as-heap=yes（但该选项会让所有内存页都进堆统计，栈就混进去了，失去区分意义）
• 编译时加了 -fomit-frame-pointer 或启用了尾调用优化，部分栈帧无法回溯，ms_print 报告里会出现 (inlined) 或空栈帧，影响归属判断
• 某些系统级调用（如 readv 带大 iovec 数组）会在内核栈上临时分配，Massif 完全捕获不到

真正想看完整内存 footprint，别只靠 Massif

Massif 的栈支持是“尽力而为”，不是“精确计量”。如果你需要知道进程真实 RSS 或 VSS，或者验证某段递归是否真把栈撑爆了，更靠谱的方式是：

• 运行时用 /proc/PID/status 查 StkSize 和 StkRef（Linux 特有）
• 用 ulimit -s 确认软限制，再结合 pthread_getattr_np() 在代码里实测当前线程栈剩余空间
• 对关键函数加 __builtin_frame_address(0) 手动打点，比依赖 Massif 的间接推算更可控

Massif 的栈功能适合快速排查“是不是栈用得异常多”，而不是替代 gdb 或内核工具做精确定界。