bison/flex 解析器的 Valgrind memcheck 结果分析

Question

我正在我的程序上运行 memcheck，并试图解决内存问题。

Memcheck 输出：

==29633== 3,443 (128 direct, 3,315 indirect) bytes in 2 blocks are definitely lost in loss record 7 of 8
==29633==    at 0x4A07D2E: operator new(unsigned long) (vg_replace_malloc.c:261)
==29633==    by 0x42027F: PDcbk(cpfrCallbackType_e, Powerdomain*) (NetExtractor.cpp:1243)
==29633==    by 0x413DBA: cpfparse() (cpf.y:120)
==29633==    by 0x42039B: loadCPF(char*) (NetExtractor.cpp:1253)
==29633==    by 0x420E5D: main (NetExtractor.cpp:1399)
==29633== LEAK SUMMARY:
==29633==    definitely lost: 128 bytes in 2 blocks
==29633==    indirectly lost: 3,315 bytes in 10 blocks
==29633==      possibly lost: 0 bytes in 0 blocks
==29633==    still reachable: 16,458 bytes in 3 blocks
==29633==         suppressed: 0 bytes in 0 blocks

NetExtractor 的第 1253 行是：

powerdomainMap.insert(Powerdomain_pair(powerdomain->getName(),new Powerdomain(*powerdomain)));

用于理解代码的信息：

PowerdomainHashMap powerdomainMap;

typedef hash_map<const string, Powerdomain*, strptrhash, strptrequal> PowerdomainHashMap;
typedef pair<const string, Powerdomain*> Powerdomain_pair;

目前我的猜测是，实际上并没有泄漏，因为我仍然可以从哈希映射访问新创建的 powerdomain，而 valgrind 无法看到这一点。

我说得对吗？如果没有有人可以解释我吗？

谢谢，请随意询问代码详细信息，因为我只粘贴了我认为相关的内容，但我可能错过了一些东西。

Answer 1

好吧，您已经有了指向 Powerdomain 类动态分配对象的指针映射。
哈希映射本身没有分配该内存，因此它不会为您清理它。
您所要做的就是在不需要时自行释放该内存，例如：

for (PowerdomainHashMap::iterator i = powerdomainMap.begin (),
     e = powerdomainMap.end (); i != e; ++i)
{
    delete i->second;
}
powerdomainMap.clear ();

您可能从未这样做过，而 Valgrind 告诉您在程序终止时该内存仍然可以访问。

现在，如果您在应用程序的生命周期内确实需要这些数据，那么就可以了，因为无论如何，操作系统都会在程序退出时清理该内存。但当然，最好是彻底关闭，这样当这个问题成为真正的问题时，您就不会因为误认为正常行为而忽视它。

除此之外，看起来你无论如何都在进行对象复制，所以我认为考虑不显式使用动态内存并让 hash_map 担心它可能是值得的。数据类型声明将如下所示：

typedef hash_map<const string, Powerdomain, strptrhash, strptrequal> PowerdomainHashMap;
typedef pair<const string, Powerdomain> Powerdomain_pair;

希望有帮助。

Answer 2

根据 memcheck 的内存泄漏是指在程序生命周期内分配但程序退出时未释放的任何内存块。由于您在 hash_map 中存储了一个指针，因此当 hash_map 被销毁时，该指针将保持未释放状态。您应该在 hash_map 中使用 shared_ptr 或使用接受指针并在集合被销毁时删除它的集合。

Answer 3

在每个 valgrind 附带的手册的常见问题解答部分中，有：

我的程序使用 C++ STL 和字符串类。 Valgrind 报告“仍然可到达”内存泄漏，涉及
这些类位于程序的出口处，但应该没有。

首先：放松一下，这可能不是一个错误，而是一个功能。 C++ 标准库的许多实现
使用自己的内存池分配器。相当多的被破坏的对象的内存不是立即被破坏的
释放并返回给操作系统，但保留在池中以供以后重新使用。事实上池没有被释放
在程序退出时导致 Valgrind 报告该内存仍然可达。行为不自由
不过，出口处的池可以称为库的错误。

使用 GCC，您可以通过全局禁用来强制 STL 使用 malloc 并尽快释放内存
内存缓存。提防！这样做可能会减慢您的程序速度，有时甚至会大幅减慢。

• 对于GCC 2.91、2.95、3.0 和3.1，使用带-D__USE_MALLOC 的STL 编译所有源代码。提防！
从版本 3.3 开始，它已从 GCC 中删除。

• 对于 GCC 3.2.2 及更高版本，您应该在之前导出环境变量 GLIBCPP_FORCE_NEW
运行你的程序。

• 在 GCC 3.4 及更高版本中，该变量已更名为 GLIBCXX_FORCE_NEW。

还有其他方法可以禁用内存池：对对象使用 malloc_alloc 模板（不是
可移植，但应该适用于 GCC），甚至编写您自己的内存分配器。但这一切都超出了
本常见问题解答的范围。首先阅读 http://gcc.gnu.org/onlinedocs/libstdc++/ faq/index.html#4_4_leak 如果您
绝对想这么做。但要注意：分配器属于 STL 中比较混乱的部分，人们会去
竭尽全力使 STL 能够跨平台移植。您的解决方案很有可能有效
您的平台，但不是其他平台。

可能你的问题是相关的。

Answer 4

您在插入操作中分配内存，该内存是否已正确释放？

我应该建议使用 STL 容器，它可以最大限度地减少您必须编写的代码量：

#include <unordered_map>
#include <string>
#include <memory>

typedef std::unordered_map<std::string, std::shared_ptr<Powerdomain> > PowerdomainMap;

这应该具有您需要的所有功能以及内置内存安全性。

在 C++98 中，使用 和 std::tr1::unordered_map 等。