valgrind未检测到内存泄漏的C语言进程内存泄漏问题如何排查

调试建议 #

• 优先核查valgrind日志中possibly lost对应的调用栈
  valgrind标记为possibly lost的内存块，绝大多数是因为分配的内存起始地址没有被指针直接指向（比如指针偏移到了内存块中部、指针被存在结构体的偏移位置等），本质上仍属于未被正确释放的泄漏内存，逐行核对这些调用栈对应的分配逻辑即可定位大部分这类问题。
• 使用valgrind massif工具追踪堆内存分配时序
  针对运行时内存持续上涨的场景，massif可以记录整个生命周期内所有堆内存分配的来源和占用变化，比默认的memcheck工具更适合定位缓慢泄漏的问题，启动命令参考：

  valgrind --tool=massif --time-unit=ms --max-snapshots=200 --massif-out-file=/tmp/massif_out.%p ./你的可执行程序
  

  程序退出后使用ms_print /tmp/massif_out.xxx即可查看不同时间点的内存占用Top调用栈。
• 替换内存分配器做泄漏检测
  若valgrind运行时性能损耗过高无法模拟真实流量场景，可以改用jemalloc/tcmalloc自带的堆剖析能力：
  以jemalloc为例，编译链接时加入jemalloc依赖，运行时添加环境变量即可生成最终堆快照：

  MALLOC_CONF=prof_leak:true,lg_prof_sample:19,prof_final:true,prof_prefix:/tmp/jeprof_out ./你的可执行程序
  

  生成的快照可以直接分析未释放内存的分配来源。
• 针对TCP客户端场景做定向排查
  重点核查以下逻辑分支：
  • 发送/接收数据包的临时缓冲区，是否所有分配的内存都在请求处理完成后释放，包括错误分支、超时分支的提前返回场景
  • 请求上下文结构体是否存入全局链表/哈希表后，请求结束未删除节点也未释放内存
  • 内核态资源是否未正确释放：比如socket fd未关闭、sendfile对应的文件句柄泄漏，这类资源泄漏也会导致进程内存占用持续升高
• 增量分模块验证
  逐块屏蔽业务逻辑：先空载运行不处理流量，确认内存是否上涨；再屏蔽响应处理逻辑仅发送请求，确认内存变化；最终缩小到泄漏对应的逻辑模块。
• 静态代码扫描辅助核查
  使用cppcheck、clang-analyzer等静态扫描工具，全量扫描代码中malloc/calloc/realloc分配后无对应free的分支场景。

内容的提问来源于stack exchange，提问作者Shighil