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 回答