如何从Valgrind获取更多信息定位可达内存块关联变量？

首先，先帮你分析下当前的情况：你看到的72,704字节的still reachable内存块，调用栈指向了libstdc++.so和动态链接初始化相关的代码，结合你提到其他用户也遇到过相同输出，这大概率是系统C++标准库的全局静态对象导致的——这类对象通常在程序生命周期内存在，进程退出时系统会直接回收内存，Valgrind会标记为"still reachable"，但本质上不属于你代码中的内存泄漏。

不过如果你还是想追踪到对应的具体变量，可以试试下面这些方法：

方法1：用Valgrind+GDB联动调试 #

通过Valgrind的vgdb功能，我们可以在内存分配的断点处直接查看调用栈和变量信息：

1. 重新运行Valgrind时加上调试联动参数：

   valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --max-stackframe=10485760 --log-file=valgrind_output.txt --vgdb=yes --vgdb-error=0 ./MyPrg
   

2. 打开另一个终端，启动GDB并连接到Valgrind：

   gdb ./MyPrg
   

   在GDB中输入：

   target remote | vgdb
   break malloc
   continue
   

3. 当程序触发那个72,704字节的malloc时，GDB会暂停，你可以用bt full查看完整调用栈，或者用info locals、info args查看当前上下文的变量信息，就能定位到分配内存的具体对象。

方法2：验证是否为系统库问题 #

因为你用的是Linux Mint 18.1，对应的libstdc++.so.6.0.21版本比较老旧，这类"still reachable"的内存块很多是标准库的已知问题，在后续版本中已经修复。你可以尝试：

• 检查系统是否有可用的libstdc++更新，升级后再重新运行Valgrind，看是否还会出现这个内存块。
• 结合其他用户的反馈，确认这个内存块是否属于标准库的全局对象（比如某些容器的全局初始化内存），这类情况完全不需要担心，不会造成实际的内存泄漏。

补充说明 #

你提到GDB调试时程序正常退出，这也侧面说明你的程序本身没有崩溃问题，这个内存块的存在不影响程序的稳定性。still reachable类型的内存和"definitely lost"不同，它是有合法指针指向的内存，只是程序退出前没有主动释放，系统会自动回收，所以一般不需要处理。

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