C++ 的 std::string 池，调试版本？ std::string 和 valgrind 问题答案

【问题标题】：C++'s std::string pools, debug builds? std::string and valgrind problemsC++ 的 std::string 池，调试版本？ std::string 和 valgrind 问题
【发布时间】：2011-03-01 02:29:08
【问题描述】：

我有很多关于 std::string 中可能存在内存泄漏的 valgrind 警告问题，比如这个：

120 bytes in 4 blocks are possibly lost in loss record 4,192 of 4,687
    at 0x4A06819: operator new(unsigned long) (vg_replace_malloc.c:230)
    by 0x383B89B8B0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)
    by 0x383B89C3B4: (within /usr/lib64/libstdc++.so.6.0.8)
    by 0x383B89C4A9: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)

我想知道：

std::string (GCC 4.1.2) 是否使用任何内存池？
如果是这样，有什么方法可以禁用池（以调试版本等形式）？

【问题讨论】：

标签： c++ string gcc memory-leaks valgrind

【解决方案1】：

120 字节对于池来说是不够的。 Do you exit() from your program?

【讨论】：

不，不退出（）。那么为什么没有池子内存可能会丢失呢？

【解决方案2】：

这似乎是误报。这可以按照manual

中的说明进行抑制

【讨论】：

【解决方案3】：

检查FAQ。有一节是关于容器中的“内存泄漏”。你应该

检查您的 Valgrind 版本
使用程序的调试版本（未优化）
并在必要时定义GLIBCXX_FORCE_NEW。（这是一个影响程序运行时行为的环境变量，而不是您可能期望的编译时#define。）

【讨论】：

【解决方案4】：

如果我没记错的话，许多 STL 分配器都实现了某种内存保留。 IE 他们不会立即释放分配的内存，而是保留并重用它。我在 valgrind 中肯定有很多误报来自我的 STL 实现分配的内存。

我发现处理该问题的最佳方法是（简单地）使用抑制文件。

【讨论】：

【解决方案5】：

我刚刚遇到这个问题，对我来说，这是因为我正在链接库的开发版本，但我的测试代码正在选择旧的系统安装版本。这些变化非常微妙，它可以链接和运行而没有任何明显的问题，但 Valgrind 会检测到奇怪的泄漏。使用ldd 代替valgrind 确认它选择了错误的库文件。设置 LD_LIBRARY_PATH 正确修复了它，尽管正确的解决方案是增加库版本，因为如果发生这种情况，它显然不再向后兼容。

当一个对象没有被正确销毁时，我也看到了这个问题，例如一个带有virtual 函数的类缺少一个virtual 析构函数。当该类被放入指向基类的指针然后被销毁时，只有基类析构函数运行，泄漏派生类中分配的任何内容，例如您的示例中的 std::string 实例。这里的提示是检查哪个类正在使用泄露的string，并按照类层次结构返回基类并确认它有一个显式的virtual 析构函数，甚至是一个空的析构函数。我假设如果类中有 virtual 函数但显然没有，它们是隐含的，并且 GCC 不会就此发出警告。

【讨论】：

【解决方案6】：

我遇到了这个问题，因为我的程序由于未捕获的异常而终止。显然，未捕获异常的处理程序并没有清理所有内容。

【讨论】：