🔒 Locked

Crt Debug problem

Started by Deliverance Aug 13, 2006 at 4:56 AM 0 replies 500+ views

Original Post

Deliverance

116

Deliverance

Aug 13, 2006 at 4:56 AM

I'm trying to detect memory leaks using the crt library I do as follows #define _CRTDBG_MAP_ALLOC #include in the WinMain function just before the return I write: _CrtDumpMemoryLeaks(); but in the debug window I receive these messages D:\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {48} normal block at 0x003D2870, 1564 bytes long. Data: 66 6F 6E 74 2F 66 6F 6E 74 00 00 00 00 00 00 00 D:\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {47} normal block at 0x003D0890, 16 bytes long. Data: < ` @ @ > 05 00 00 00 60 19 40 00 00 01 00 00 09 11 40 00 D:\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {45} normal block at 0x003D0800, 4 bytes long. Data: < @ > 86 16 40 00 D:\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {44} normal block at 0x003D07B8, 4 bytes long. Data: 6E 10 40 00 I want to know the name of the file where the leak occured , why is this D:\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h? instead of one of the files in my project? I know that the new and delete are redefined here D:\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h? but I want to know the file in my project that causes the leak, this would be more useful soi where am I doing it wrong? [Edited by - Deliverance on August 13, 2006 5:39:30 AM]

SiCrane

Mod

473

SiCrane

Aug 13, 2006 at 7:58 AM

Reading the manual helps some. From Tracking Heap Allocation Requests:

Quote:

The simplest way to identify the specific heap allocation call that went bad is to take advantage of the unique allocation request number associated with each block in the debug heap. When information about a block is reported by one of the dump functions, this allocation request number is enclosed in curly brackets (for example, “{36}”).

Once you know the allocation request number of an improperly allocated block, you can pass this number to _CrtSetBreakAlloc to create a breakpoint. Execution will break just prior to allocating the block, and you can backtrack to determine what routine was responsible for the bad call. To avoid recompiling, you can accomplish the same thing in the debugger by setting _crtBreakAlloc to the allocation request number you are interested in.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.