Deciphering memory leak dump
-
I'm getting this object dump from a memory leak.... Detected memory leaks! Dumping objects -> {75} normal block at 0x00335668, 8 bytes long. Data: < > 01 00 00 00 02 00 00 00 {74} normal block at 0x00335600, 40 bytes long. Data: < B hV3 > A0 EE 42 00 C4 FD 12 00 68 56 33 00 02 00 00 00 {73} normal block at 0x003355B0, 16 bytes long. Data: < B 8 V3 > 14 EF 42 00 02 00 00 00 38 FE 12 00 00 56 33 00 {70} normal block at 0x003353A0, 380 bytes long. Data: 44 67 04 10 1C 67 04 10 B0 55 33 00 01 00 00 00 Object dump complete. Is there any information in here that will help me track down the problem? it all looks like gobbledygook to me.
-
I'm getting this object dump from a memory leak.... Detected memory leaks! Dumping objects -> {75} normal block at 0x00335668, 8 bytes long. Data: < > 01 00 00 00 02 00 00 00 {74} normal block at 0x00335600, 40 bytes long. Data: < B hV3 > A0 EE 42 00 C4 FD 12 00 68 56 33 00 02 00 00 00 {73} normal block at 0x003355B0, 16 bytes long. Data: < B 8 V3 > 14 EF 42 00 02 00 00 00 38 FE 12 00 00 56 33 00 {70} normal block at 0x003353A0, 380 bytes long. Data: 44 67 04 10 1C 67 04 10 B0 55 33 00 01 00 00 00 Object dump complete. Is there any information in here that will help me track down the problem? it all looks like gobbledygook to me.
a) compile with (more) debug info, if possible b) start at bottom, the later allocations might be dependent on the bottom one. c) does the size of the structure ring a bell? b) the first number is the "allocation number" (i.e. the 70th allocation leaks memory) Typically they are "stable". If so, you can use _CrtSetAllocHook, which gets called for each allocation, set a cond breakpoint for allocation number == 70, and look at the stack trace from there.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen -
I'm getting this object dump from a memory leak.... Detected memory leaks! Dumping objects -> {75} normal block at 0x00335668, 8 bytes long. Data: < > 01 00 00 00 02 00 00 00 {74} normal block at 0x00335600, 40 bytes long. Data: < B hV3 > A0 EE 42 00 C4 FD 12 00 68 56 33 00 02 00 00 00 {73} normal block at 0x003355B0, 16 bytes long. Data: < B 8 V3 > 14 EF 42 00 02 00 00 00 38 FE 12 00 00 56 33 00 {70} normal block at 0x003353A0, 380 bytes long. Data: 44 67 04 10 1C 67 04 10 B0 55 33 00 01 00 00 00 Object dump complete. Is there any information in here that will help me track down the problem? it all looks like gobbledygook to me.
I use: #define _CRTDBG_MAP_ALLOC #include at the top of my application, and: _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); at the start of my application (first function). More information about the object that caused the memory leak will appear in the debug information.
-
a) compile with (more) debug info, if possible b) start at bottom, the later allocations might be dependent on the bottom one. c) does the size of the structure ring a bell? b) the first number is the "allocation number" (i.e. the 70th allocation leaks memory) Typically they are "stable". If so, you can use _CrtSetAllocHook, which gets called for each allocation, set a cond breakpoint for allocation number == 70, and look at the stack trace from there.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygenpeterchen wrote: If so, you can use _CrtSetAllocHook, which gets called for each allocation, set a cond breakpoint for allocation number == 70, and look at the stack trace from there. You can do it one step using _CrtSetBreakAlloc(70) at the beginning of the program.
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
-
I'm getting this object dump from a memory leak.... Detected memory leaks! Dumping objects -> {75} normal block at 0x00335668, 8 bytes long. Data: < > 01 00 00 00 02 00 00 00 {74} normal block at 0x00335600, 40 bytes long. Data: < B hV3 > A0 EE 42 00 C4 FD 12 00 68 56 33 00 02 00 00 00 {73} normal block at 0x003355B0, 16 bytes long. Data: < B 8 V3 > 14 EF 42 00 02 00 00 00 38 FE 12 00 00 56 33 00 {70} normal block at 0x003353A0, 380 bytes long. Data: 44 67 04 10 1C 67 04 10 B0 55 33 00 01 00 00 00 Object dump complete. Is there any information in here that will help me track down the problem? it all looks like gobbledygook to me.