valgrind --tool=memcheck 不能直接看出循环内存增长，仅报告进程退出时的泄漏（如 definitely lost），无法反映运行中堆内存的动态变化；需改用 --tool=massif 配合 ms_print 分析 mem_heap_b 趋势，并结合 --stacks=yes 和 valgrind_do_leak_check 定位具体分配点。
valgrind --tool=memcheck 能不能直接看出循环内存增长
不能。默认的 memcheck 只报告“泄漏”（程序退出时仍被持有的内存），而循环中反复 malloc 后没 free，但每次又把指针覆盖掉——这种“活着但再也访问不到”的内存，memcheck 会归类为 definitely lost，但它不会告诉你“第 100 次迭代比第 10 次多占了 2MB”。你需要主动触发快照对比。
怎么用 --trace-children=yes + --time-stamp=yes 配合手动采样
Valgrind 本身不提供实时内存曲线，但可以靠时间戳+多次中断来定位增长点：
- 加
--time-stamp=yes让输出每行带毫秒级时间，方便对齐循环轮次 - 用
--trace-children=yes确保子进程（比如你用system()调外部命令）也被监控 - 在循环里加个轻量级触发点：比如每 10 次迭代
fprintf(stderr, "ITER %d\n", i);，然后用grep "ITER\|total heap usage"过滤日志 - 别依赖
--leak-check=full的最终汇总——它只在进程退出时跑一次；你要的是中间态
更靠谱的做法：用 --tool=massif + massif-visualizer 或 ms_print
massif 是专为内存增长趋势设计的工具，它能记录堆内存随时间/指令数的变化：
- 运行：
valgrind --tool=massif --massif-out-file=massif.out ./your_program - 生成的
massif.out是文本，含每个快照的mem_heap_B（当前堆使用字节数）、mem_heap_extra_B、调用栈等 - 用
ms_print massif.out | head -50快速看前几个峰值，找mem_heap_B持续上升的区间 - 关键技巧：在循环入口加
VALGRIND_DO_LEAK_CHECK（需#include <valgrind></valgrind>），这样massif快照会和你的逻辑节点对齐
为什么 malloc/free 配对了还涨？常见坑在哪
即使代码看着 free 了，内存仍上涨，大概率是这几类问题：
- 指针被意外重赋值，导致旧地址丢失（比如
p = malloc(100); p = malloc(200);—— 第一块永远漏了） - 结构体里有指针成员，只 free 了结构体本身，忘了
free(p->data) - 用了
realloc但忽略返回值（失败时返回NULL，原内存未释放，你还继续用旧指针） - 第三方库分配的内存（如
strdup、curl_easy_init）需要对应方式释放，不是一律free -
massif显示mem_heap_B上涨但mem_stacks_B不变，基本可排除栈溢出，聚焦堆管理逻辑
真正难的不是发现涨，而是确认哪一行分配没被回收——massif 输出里的 allocs 和 deallocs 数量差，配合 --stacks=yes 打出的调用栈，才是定位根因的关键线索。
