Linux怎么查看具体内存泄漏追踪日志

Valgrind泄漏日志默认输出到终端，易丢失，必须用--log-file=valgrind.log显式指定文件；关键看definitely lost和possibly lost项，需编译时加-g才能定位源码行。

valgrind生成的泄漏日志在哪看

valgrind不会把结果写进系统日志或/var/log，它默认直接输出到终端。如果程序运行时间长、输出多，终端刷屏后容易丢失关键信息，必须重定向。

常见错误是只执行valgrind ./a.out然后盯着屏幕等，结果泄漏报告被后续日志冲掉，或者程序后台运行后根本看不到输出。

• 加--log-file=valgrind.log显式指定输出文件，这是最稳妥的做法
• 若已漏掉输出，且程序支持重复运行，立刻补跑：valgrind --leak-check=full --log-file=valgrind.log ./your_program
• 日志里真正要盯的是definitely lost和possibly lost两块，不是still reachable——后者通常是全局指针持有，不一定是泄漏
• 确保二进制带调试符号（编译时加-g），否则日志里只显示???或地址，无法定位到源码行

mtrace的日志文件路径怎么确定

mtrace不自动创建日志，它完全依赖环境变量或代码中提前设置的路径。没设就等于没记录，跑完也不会生成任何文件。

最容易踩的坑是：写了mtrace()调用，却忘了设MALLOC_TRACE，结果test.log始终为空。

• 运行前必须执行export MALLOC_TRACE=./mtrace.log（注意路径要有写权限）
• 也可以在代码里调用setenv("MALLOC_TRACE", "mtrace.log", 1)，但必须在mtrace()之前
• 日志内容是纯文本，每行形如+ 0x7f8b1c000000 0x100，需要用mtrace命令解析：mtrace ./your_program mtrace.log
• 解析后会打印出未配对的malloc调用位置，格式类似Memory not freed: 0x00007f8b1c000000 (100 bytes) at ./test.c:12

/sys/kernel/debug/kmemleak怎么读取内核泄漏日志

这个接口不是“日志文件”，而是一个动态调试节点，每次cat都触发一次即时扫描并返回当前快照。不能像普通日志那样用tail -f持续监听。

很多人误以为cat /sys/kernel/debug/kmemleak会输出历史累积记录，其实它只返回最近一次扫描发现的孤立对象，且默认10分钟才扫一次。

• 首次使用前确认debugfs已挂载：mount -t debugfs nodev /sys/kernel/debug
• 手动触发扫描：echo scan > /sys/kernel/debug/kmemleak，再cat才有效
• 输出里每段以object 0xffff9a8b12345678开头，后面跟着分配时的栈回溯，关键看最后一级函数是不是你的驱动模块名
• 如果看到大量kmalloc-64或size-32缓存对象堆积，且slabtop里对应NUM OBJS持续增长，基本可锁定内核态泄漏

pmap -x输出里哪列反映内存泄漏趋势

pmap -x本身不判断泄漏，它只是快照。泄漏判断靠的是**多次采样对比**，重点不是单次数值，而是变化规律。

新手常盯着SIZE列看，但SIZE是虚拟内存，包含未实际分配的保留空间，涨了未必真泄漏；反而RSS（物理内存驻留集）持续单向增长才是强信号。

• 执行pmap -x <pid></pid>至少3次，间隔10–30秒，记录每次的RSS值
• 如果RSS从100MiB → 150MiB → 210MiB → 280MiB，斜率稳定上升，基本可断定用户态堆泄漏
• 配合pmap -XX <pid></pid>看[anon]映射块数量和大小，若出现大量1MB或4KB的匿名页，大概率是malloc未free
• 注意排除缓存干扰：如果buffers/cache也同步涨，可能是程序主动缓存数据，需结合业务逻辑判断是否合理

所有这些工具输出的“日志”都不是开箱即用的结论，而是线索拼图。真正难的不是找到文件，而是从definitely lost、+ 0x7f... 0x100、object 0xffff...或不断上涨的RSS里，确认哪一个是真实泄漏点，而不是误报或正常行为。