链接 POCO C++ 库会导致大量内存泄漏答案

【问题标题】：Linking POCO C++ Library gives numerous memory leaks链接 POCO C++ 库会导致大量内存泄漏
【发布时间】：2011-09-16 13:16:44
【问题描述】：

我刚刚开始尝试将 Poco C++ 库与我们的游戏引擎集成，但是每次我链接 /usr/lib/libPocoFoundation.so 时，我的程序突然出现 51 次内存泄漏。删除链接选项可以消除所有泄漏（它们都不是来自我的代码）。即使我从我的 c++ 文件中删除所有 Poco #includes，也会发生这种情况。

我怀疑 Poco 的 Foundation（核心）方法确实存在 51 次内存泄漏 - 搜索他们的论坛并没有发现任何问题，我相信其他用户会注意到这种明显的事情。我认为这更有可能是我如何链接到 Poco 的问题？

我在 Ubuntu 11 上，使用 Code::Blocks 作为 IDE，使用 g++ 4.5.2 构建，并从 ubuntu ppa (sudo apt-get install libpoco-dev libpoco-doc) 获取 Poco 1.3.6p1-1build1。

任何关于问题可能是什么的建议都非常受欢迎！我唯一能想到的是我没有正确链接 Poco。

可能相关：c-poco-lib-linking-error-when-trying-static-linking-vs9-express 的 OP 提到了一些关于“添加预处理器标志 Foundation_EXPORTS POCO_STATIC PCRE_STATIC”的内容 - 那会做什么？我在 Poco 参考页面上看不到有关如何正确链接 Poco 的任何信息。

【问题讨论】：

标签： c++ memory-leaks poco

【解决方案1】：

你没有说是什么工具告诉你有内存泄漏，但我会假设它是 valgrind，因为你在 Ubuntu 上。

如果即使您没有调用任何 POCO 方法也发生泄漏，那么很可能这些是在 POCO 库的静态初始化期间发生的一次性分配，无论出于何种原因，以后都不会被拆除。

虽然这对库而言并不是特别好的行为，但也不是致命的。您应该担心的泄漏是会反复发生并会逐渐消耗内存的泄漏。

我建议现在使用valgrind --gen-suppressions=all 为一次性泄漏生成抑制（特别好，您不调用任何 POCO 方法）。然后，查看 POCO 库，看看您是否可以弄清楚为什么这些分配没有在 .fini 时间解除。如果可以的话，太好了，让 POCO 人员修复您的问题，然后您就可以删除您的禁止条目。如果没有，请将它们保留下来，这样这些“误报”就不会干扰在您的代码中发现真正有害的内存泄漏。

【讨论】：

使用我们的自定义调试文件检测到泄漏 - 基于wyw.dcweb.cn/leakage.htm。阅读您的帖子后，我尝试在 valgrind 中运行程序（有和没有 Poco 链接），它报告了 OpenGL 和 X 窗口系统的一些泄漏，但 Poco 没有。这很糟糕，因为我们的内存监视器到目前为止还没有任何问题，但它显然存在一些问题。
我明白了。好吧，我并不是说您的自定义调试分配器不是一个很酷的项目。然而，在测试你的实现的准确性时，至少可以考虑使用一个经过验证的真实的，比如tcmalloc，作为一个数据点。性能也很难被击败（当然在非调试模式下）。此外，valgrind 几乎是 UNIX 和 Linux 上泄漏检测的黄金标准。遗憾的是，tcmalloc 和 valgrind 不能很好地结合在一起。我一直想做的事情......
确实 - 我现在会坚持使用 Valgrind。我已将您的答案标记为正确，因为阅读它有助于揭示实际问题所在。谢谢@acm

【解决方案2】：

某些对象必须通过调用方法“释放”来释放

以下是 doc poco 的摘录

" DOMObject 定义了此 DOM 实现中的内存管理规则。违反这些规则（如下所述）会导致内存泄漏或悬空指针。

当不再需要时，必须通过调用 release() 或 autoRelease() 来释放由 new 或工厂方法（例如 Document::create*）创建的每个对象。 "

【讨论】：

这是正确答案。这里确实存在泄漏，需要 release() 来释放内存。我在 poco 对象上调用了 release() 并且 valgrind 投诉消失了。抑制 valgrind 确实隐藏了泄漏。
不过，更正确的方法是将 poco 对象包装在 AutoPtr 中。