为什么 _CrtSetBreakAlloc 不会导致断点？
我正在使用 _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的说明如何在内存分配上设置断点number，我应该能够通过此调用在第 133 个分配上设置断点：
_CrtSetBreakAlloc(133);
并且我还可以在监视窗口中验证 {,,msvcr90d.dll}_crtBreakAlloc 确实已设置到 133。程序退出后，泄漏报告仍然列出#133（以及一些更高的数字），但没有出现断点。为什么会出现这种情况以及如何让断点发生？
可能相关的信息：
- VS2008，使用“多线程调试DLL”CRT
- 我的代码是一个由第三方产品加载的DLL
- “正常”断点工作得很好；单步执行效果很好；
__asm int 3也可以正常工作。 _crtBreakAlloc没有其他值会导致断点（无论如何不是我尝试过的）- #133 是泄漏报告中的最低数字
I'm using Visual CRT's memory leak detection routines from <crtdbg.h>; when I call _CrtDumpMemoryLeaks one allocation is reported consistently on every invocation of the program:
{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
The address varies but {133} is always the same.
According to MSDN's instructions on How to set breakpoints on memory allocation number, I should be able to set a breakpoint on the 133rd allocation with this call:
_CrtSetBreakAlloc(133);
and I can also verify in the watch window that {,,msvcr90d.dll}_crtBreakAlloc is indeed set to 133. After the program exits, the leak report still lists #133 (along with some higher numbers), but no breakpoint occurs. Why might this be and how do I get the breakpoint to occur?
Potentially relevant info:
- VS2008, using the "multi-threaded debug DLL" CRT
- My code is a DLL that gets loaded by a third-party product
- "Normal" breakpoints work just fine; stepping through works fine;
__asm int 3works fine too. - No other value for
_crtBreakAlloccauses a breakpoint either (not the ones I tried anyway) - #133 is the lowest number in the leak report
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
主要的额头拍打...一个“明显”的原因是如果分配#133发生在设置断点之前...
只是第一次泄漏发生在我的DLL被调用之前。事实上，这不一定是泄漏，因为我在卸载 DLL 时调用
_CrtDumpMemoryLeaks，而不是在父应用程序完成反初始化时调用。至于我原来的问题中的“潜在相关信息#4” - 我确实尝试了一些值，但不知何故没有一个高于 133...
Major forehead slapping... One "obvious" reason is if allocation #133 occurred before the breakpoint was set...
It's just that the first leak turns out to occur before my DLL gets invoked. In fact it's not necessarily a leak, because I call
_CrtDumpMemoryLeakswhen the DLL is unloaded - not when the parent application is done deinitializing.As for "Potentially relevant info #4" in my original question - well I did try a few values, but somehow none were higher than 133...
听起来您可能正在使用非调试库来编译您的应用程序，例如。如果您使用的库的发布版本会破坏您的应用程序，则它不会这样做。发生这种情况可能是因为您使用了第 3 方应用程序。也有可能在运行时加载非调试 dll 来代替调试 dll。
尝试在调试时查看是否为您的应用程序加载了正确的 DLL，以及应用程序或 DLL 是否实际已调试。 （有时您必须明确地将 dll 或 exe 加载到调试器中。）
这就是我能想到的所有内容，而没有看到有关此的更多详细信息...
It sounds like you might be compiling your app with a non-debug lib, eg. if you use the release version of the lib that should break your app, it will not do that. It's possible that this happens because you use the 3rd party app. It's also possible that the non-debug dll is loaded in place of the debug one at runtime.
Try to see if the right DLL-s are loaded for your app while debugging and also that the app or DLL is actually debugged. (Sometimes you explicitly have to load the dll or exe into the debugger.)
This is all that I can think of without seeing more details about this...