Menu
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:
__asm int 3 works fine too._crtBreakAlloc causes a breakpoint either (not the ones I tried anyway)
533
To find memory leaks and inefficient memory usage, you can use tools such as the debugger-integrated Memory Usage diagnostic tool or tools in the Performance Profiler such as the . NET Object Allocation tool and the post-mortem Memory Usage tool.
The primary tools for detecting memory leaks are the C/C++ debugger and the C Run-time Library (CRT) debug heap functions. The #define statement maps a base version of the CRT heap functions to the corresponding debug version. If you leave out the #define statement, the memory leak dump will be less detailed.
The most common and most easy way to detect is, define a macro say, DEBUG_NEW and use it, along with predefined macros like __FILE__ and __LINE__ to locate the memory leak in your code. These predefined macros tell you the file and line number of memory leaks.
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 _CrtDumpMemoryLeaks when 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...
151
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...
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
