Question

我正在编写一些Windows软件，当它终止时，我收到了很多不正确的内存泄漏消息：

Detected memory leaks!
Dumping objects ->
{29745} normal block at 0x02938E38, 36 bytes long.
 Data: <, E             > 2C 0B 45 10 00 00 00 00 01 00 00 00 01 CD CD CD 
{29732} normal block at 0x02938C08, 500 bytes long.
 Data: <X)A         `  @> 58 29 41 10 00 00 00 00 01 00 00 00 60 93 0B 40 
{29721} normal block at 0x028DA8A0, 84 bytes long.
 Data: < 1D         0 %i> C8 31 44 10 00 00 00 00 01 00 00 00 30 85 25 69

我确信这些都是误报。你对此有什么建议吗？随着软件的发展，可能会出现一些实际的漏洞，至少可以说难以找到它们。

修改：
我应该提到我正在使用名为OpenSceneGraph的库。它在内部引用了大量智能指针。所有这些泄漏都是我new然后传递到库中的实例，该库立即将其包装在ref_ptr<>中。我知道实例没有泄漏，因为我已经将fprintf添加到析构函数中，并且当智能指针超出范围时我确实看到了消息。不久之前，微软有一个类似于标准库的问题，我想知道我是否在这里看到类似的东西？显然，该错误与某些_CRT_BLOCKS被标记为_NORMAL_BLOCKS相关。

编辑2 ：

我弄明白发生了什么。转储内存泄漏信息的代码在所有静态数据超出范围之前发生。在一种情况下，内部对象是通过原型模式构建的，原型对象是静态的，因此在atexit机器启动之前不会被破坏。因此，没有任何东西真正泄漏。只是在应用程序拆除发生之前就发生了转储。

Answer 1

我发现这些都是误报。他们在Pragmatic Programmer，SELECT isn't broken中说。

Answer 2

哪个编译器？

获取另一个分析/泄漏检测工具。（Boundschecker等）

我过去得到的误报从未阻止我发现“真正的”泄密。

我不同意其他人说你误报了误报 - 但要仔细检查 - 检查所有“新”并跟踪应用程序逻辑以说服自己这些都是错误的。

您还可以在对象中添加警卫或标签或记忆签名，以确保它们不是您创建的内容。

不确定告诉你关于第三方的事情。我会联系第三方软件公司，询问他们是否知道任何问题 - 误报或其他。

Answer 3

我也会说你很可能有真正的韭菜（它们也可能是你正在使用的第三方代码）。

但是有一种方法可以准确找到未发布的分配。见这里：http://msdn.microsoft.com/en-us/library/w2fhc9a3(VS.71).aspx

（当然，对于其他版本的VS，您必须更改此处的dll名称：

{,,msvcr71d.dll}_crtBreakAlloc

到正确的版本（msvcr90d.dll = VS 2008，msvcr80d.dll = VS 2005，msvcr71d.dll = VS 2003，msvcr70d.dll = VS 2002）

Answer 4

当我之前遇到这个问题（似乎被删除的东西显示为泄露）时，通常是因为我忘记了或没有考虑指针分配替换我新的那个。

然后它“似乎”删除就好了，而原来的新对象泄漏了。

Answer 5

VS为在.dll（不使用MFC）中分配为静态的内存泄漏内存报告，因为报告是（出于某种原因）在.dll被删除之前生成的（并且它们将被正确地解除分配）当dll卸载时）。因此误报。

在Windows上处理不正确的内存泄漏报告

5 个答案: