使用Valgrind+GDB排查多线程进程内存泄漏问题

1. 让Valgrind直接输出带线程标识的泄漏报告 #

启动程序时添加参数，让Valgrind完整记录每个内存分配的归属线程：

valgrind --leak-check=full --show-reachable=yes --track-origins=yes --verbose ./your_program

报告里每个内存分配条目都会明确标注Thread X（X为线程ID），你可以直接搜索Still reachable相关条目，对应到具体线程后查看调用栈找到分配点。

2. 在GDB+Valgrind环境下定向排查线程 #

当你用GDB附加到Valgrind运行的程序后，按以下步骤操作：

• 执行info threads，获取所有线程的编号、函数栈，以及末尾的LWP xxxx（轻量级进程ID）。
• 逐个暂停可疑线程：切换到目标线程（thread <线程编号>），执行pause，然后继续运行程序并执行monitor leak_check。如果内存不再增长，说明被暂停的线程就是内存分配的来源。
• 精准跟踪单个线程的分配：用Valgrind的monitor track-malloc命令指定跟踪某线程，比如：

  monitor track-malloc on <lwp-number>
  

  之后执行monitor leak_check时，只会显示该线程的内存分配情况，排除其他线程干扰。

3. 用Massif工具分析内存增长趋势 #

Massif是Valgrind专门用于内存增长分析的工具，能按时间维度展示各线程的内存占用：

• 启动命令：

  valgrind --tool=massif --heap=yes --heap-admin=0 --massif-out-file=massif.out ./your_program
  

• 生成可读报告：

  ms_print massif.out
  

  报告里会包含每个时间点的内存峰值，以及对应线程的调用栈。加上--detailed-freq=1参数，还能看到更细粒度的线程分配细节。

额外提示 #

你遇到的Still reachable内存增长，说明这些内存仍被指针引用，程序退出时会自动释放，但运行中持续积累。常见原因是全局线程安全容器（如队列、哈希表）不断添加元素未清理，或者线程本地存储（TLS）中的对象持续创建。结合线程跟踪，能快速锁定问题线程。

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