无法跟踪 Visual Studio 内存泄漏答案

【问题标题】：Visual Studio Memory leaks cannot be traced无法跟踪 Visual Studio 内存泄漏
【发布时间】：2015-10-09 18:03:39
【问题描述】：

https://msdn.microsoft.com/en-us/library/x98tx3cf.aspx#NotExistJustToMakeTheAElementVisible

我正在使用上述站点来清除我的项目的内存泄漏，我终于能够消除一个困扰我一个多月的问题。

然而，当使用

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

指令并尝试根据内存分配数设置断点，使用

_crtBreakAlloc = 425;

例如，我没有得到断点。然而，我的调试输出显示：

'SMP.exe' (Win32): Unloaded 'C:\Windows\System32\winmm.dll'
The thread 0x2e90 has exited with code 0 (0x0).
Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\occcont.cpp(922) : {425} normal block at 0x0000000000725180, 24 bytes long.
 Data: <R               > 52 04 15 00 00 00 00 00 00 00 00 00 00 00 00 00 
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\occcont.cpp(922) : {424} normal block at 0x0000000000725100, 24 bytes long.
 Data: <,               > 2C 04 1B 00 00 00 00 00 00 00 00 00 00 00 00 00 
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\occcont.cpp(922) : {423} normal block at 0x0000000000725080, 24 bytes long.
 Data: <  I             > BC 0C 49 00 00 00 00 00 00 00 00 00 00 00 00 00 
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\occcont.cpp(922) : {422} normal block at 0x0000000000725000, 24 bytes long.
 Data: <j               > 6A 05 16 00 00 00 00 00 00 00 00 00 00 00 00 00

这些泄漏大约有 280 个，我没有将它们全部列出，但我无法使用上述命令在任何这些分配处设置断点。这种做法有助于消除我提到的其他内存泄漏，我确实修复了。

另外，FWIW，我不知道这个 occont.cpp 文件是什么，它在哪里，或者它对我的项目做了什么。

任何关于此事的信息/建议将不胜感激。谢谢！

【问题讨论】：

是否有可能消除所有“报告的”内存泄漏？我以前使用这些工具来查找大泄漏，但我不确定是否可以消除所有问题。
你知道，我也在想同样的事情......我没有使用 f:\ 驱动器上的任何文件，而且它们甚至出现在报告中是很神秘的。我不知道这些是否是真正的担忧。我之前已经处理了所有重大泄漏，现在我正在处理这些小问题
是的，“f:\dd\vctools\vc7libs\”中的任何内容都将成为 Visual Studio 或 Windows SDK 内容的一部分。因为内存调试器绝对拦截每一个内存分配，它很容易出现误报。也不建议注意程序退出时发现的“泄漏”，因为有很多东西没有“正确”清理，因为程序正在退出，而且无论如何它都会在几毫秒内没有实际意义。
" 也不建议注意程序退出时发现的“泄漏”——除非这些泄漏是由您的代码引起的，如果不修复它们可能会累积超时导致内存问题

标签： c++ visual-studio-2012 memory memory-leaks

【解决方案1】：

为了使用_crtBreakAlloc = 425; 检测内存泄漏，您必须在分配编号 425 发生之前设置它。显然，这在您设置它时已经发生，因此您没有断点。

假设您已将语句放在main 中，您可以通过将其放在main 的外部作为静态变量初始化器来使其更早执行。

static int breakAlloc = (_crtBreakAlloc = 425);

评论者所说的内容很多。如果应用程序正在退出，那么从技术上讲根本不会泄漏任何东西，因为当它们进程退出时，操作系统将回收所有内容。在这种情况下，清理内存可能是浪费时间，而提前退出是一种性能提升。所以这可能是设计使然。

正如 cmets 中所指出的，这些分配是由库代码进行的。因此，潜在的问题可能是：1）您需要调用某种底层库关闭例程，并且可能由此产生其他负面后果，或者 2）这是由于过早调用 _CrtDumpMemoryLeaks 而导致的误报（也许这些只是即将被清理）或 3）它甚至可能是设计使然（但可能不是）。

如果所有分配数都很低，(

【讨论】：