应根据场景选择工具：valgrind适合开发测试阶段深度诊断，mtrace适合轻量、低侵入的运行时跟踪。valgrind通过动态插桩精准定位泄漏文件行号与调用栈，需-g编译且禁高优化；mtrace为glibc内置轻量方案，仅需两行代码加环境变量，生成文本日志解析泄漏点。
Linux进程内存泄漏排查，关键在于匹配问题场景选对工具。Valgrind适合开发测试阶段做深度诊断，mtrace更适合轻量、低侵入的运行时跟踪，尤其在资源受限或需长期驻留的环境中。
Valgrind：精准定位泄漏源头
Valgrind的memcheck工具通过动态二进制插桩，在程序运行时实时监控每一块堆内存的分配、释放、读写状态。它能报告泄漏发生的具体文件、行号、调用栈，甚至指出“definitely lost”（确定泄漏）和“possibly lost”（潜在泄漏）的区别。
- 编译时必须加 -g 保留调试信息，避免使用 -O2 及以上优化，否则行号可能错乱或内联导致栈丢失
- 常用命令：valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./myapp
- 输出中重点关注 "definitely lost" 条目——这是最可靠的泄漏证据；"still reachable" 通常是正常未释放的全局缓存，不一定是问题
- 对多线程程序同样有效，但会显著拖慢运行速度（通常慢10–30倍），不适合线上实时服务
mtrace：简单、零依赖、低开销
mtrace是Glibc自带的轻量方案，不改变程序执行逻辑，只在malloc/free等调用点埋入日志记录钩子。它生成纯文本日志，体积小、易导出，特别适合嵌入式设备或生产环境短期采样。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 代码中只需两处改动：包含 #include
，并在main开头调用 mtrace()，结尾调用 muntrace() - 运行前设置环境变量：export MALLOC_TRACE=./mtrace.log；也可在代码中用 setenv("MALLOC_TRACE", "path", 1) 动态指定
- 程序退出后，用 mtrace ./myapp ./mtrace.log 解析日志——未配对的 +（malloc）即为泄漏点，附带地址与大小
- 不支持检测越界、use-after-free等高级问题，但对“忘了free”这类基础泄漏反应直接、无误报
怎么选？看这三点
不是越重的工具越好，而是看你要回答什么问题：
- 刚写完模块，想确认有没有漏掉free？ → 用mtrace，5分钟接入，日志一目了然
- 进程RSS持续上涨，但不确定是哪段代码？ → 先用top/ps锁定PID，再用Valgrind复现并精确定位
- 跑在ARM嵌入式设备上，不能装额外软件？ → mtrace是唯一选择，Glibc默认带，无需交叉编译Valgrind
配合使用效果更好
实际排查中，建议先用mtrace快速扫一遍，确认是否存在基础泄漏；若有，再用Valgrind深入分析调用路径和上下文。例如：mtrace发现某次malloc没被free，Valgrind就能告诉你这次malloc是在config_load()里被调用的，而该函数在异常分支中跳过了清理逻辑——二者结合，问题闭环就完整了。
