15

我正在使用 Visual CRT 的内存泄漏检测例程<crtdbg.h>；当我调用_CrtDumpMemoryLeaks一个分配时，程序的每次调用都会一致地报告：

{133} normal block at 0x04F85628, 56 bytes long.
 Data: <                > B0 81 F8 04 B0 81 F8 04 B0 81 F8 04 CD CD CD CD

地址不同，但{133}始终相同。

根据 MSDN 关于How to set breakpoints on memory allocation number的说明，我应该能够通过此调用在第 133 个分配上设置断点：

_CrtSetBreakAlloc(133);

而且我还可以在监视窗口中验证{,,msvcr90d.dll}_crtBreakAlloc确实设置为 133。程序退出后，泄漏报告仍然列出 #133（以及一些更高的数字），但没有出现断点。为什么会这样？如何让断点发生？

潜在相关信息：

  1. VS2008，使用“多线程调试DLL”CRT
  2. 我的代码是由第三方产品加载的 DLL
  3. “正常”断点工作得很好；逐步完成工作正常；__asm int 3工作也很好。
  4. 也没有其他值_crtBreakAlloc导致断点（不是我尝试过的那些）
  5. #133 是泄漏报告中的最低数字
4

2 回答 2

9

主要的额头拍打......一个“明显”的原因是如果分配＃133发生在断点设置之前......

只是第一次泄漏发生在我的 DLL 被调用之前。事实上，它不一定是泄漏，因为我_CrtDumpMemoryLeaks在卸载 DLL 时调用 - 而不是在父应用程序完成反初始化时调用。

至于我最初的问题中的“潜在相关信息#4”——我确实尝试了一些值，但不知何故没有一个高于 133 ......

于 2010-02-09T01:36:10.573 回答
1

听起来您可能正在使用非调试库编译您的应用程序，例如。如果您使用应该破坏您的应用程序的 lib 的发布版本，它不会这样做。发生这种情况可能是因为您使用的是 3rd 方应用程序。也有可能在运行时加载非调试 dll 代替调试 dll。

尝试查看在调试时是否为您的应用加载了正确的 DLL-s，以及该应用或 DLL 是否已实际调试。（有时您必须明确地将 dll 或 exe 加载到调试器中。）

在没有看到更多细节的情况下，这就是我能想到的一切......

于 2010-02-09T00:50:23.657 回答