Identifying Memory leak location

ganesh dp

VC reporting some memory leaks in my application but without line number and file name. because of that i can't locate the leak. Report is given below

Detected memory leaks!
Dumping objects ->
{159399} normal block at 0x04D98460, 1024 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{159398} normal block at 0x044E4F30, 36 bytes long.
Data: <HG ` ` > 48 47 97 01 A2 CD CD CD 60 84 D9 04 60 84 D9 04
{159397} normal block at 0x04D98028, 1024 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{159396} normal block at 0x04CABF20, 68 bytes long.
Data: <(H ( ( > 28 48 97 01 A2 CD CD CD 28 80 D9 04 28 80 D9 04
{159393} normal block at 0x044F37F0, 36 bytes long.
Data: < 7O 8PN 7O > F0 37 4F 04 38 50 4E 04 F0 37 4F 04 CD CD CD CD
{159392} normal block at 0x044E5038, 36 bytes long.
{21242} normal block at 0x04507C18, 4 bytes long.
The program 'D:\Kty\Program\kty.exe' has exited with code 0 (0x0).

How can I locate leak?

Aescleal

First thing to do is to avoid manually managing memory - then you won't have so many options for leaking memory. Replace raw pointers with decent smart pointers or just use automatic objects where you can. Secondly there are some biggish blocks in there. Have a look in you code for anywhere you use big buffers that you dynamically allocate. As the blocks are only 1k in size just throw them on the stack. After that if you're still having problems start thinking about using a diagnostic new and delete so you can start getting a handle on what you're allocating and not freeing. Cheers, Ash

ganesh dp

thanks for reply. After that if you're still having problems start thinking about using a diagnostic new and delete so you can start getting a handle on what you're allocating and not freeing "diagnostic new and delete" - Can u explain it in detail

Niklas L

There are some other hints in there as well. The compiler makes sure allocated memory is filled with the value 0xCD for debug builds. That way the debugger can warn the user if you're trying to read uninitialized data. As you can see, both leaks of size 1024, seem to be unused. Also 1024 is a neat number, and I bet you could just search in your source code for '1024'. Someone is probably allocating a buffer they think is big enough for a task. You can also see the 'CD' pattern in the other dumps, indicating how the original layout might be. Assuming you have not altered the packing, it looks like the first 36 byte leak comes from a class or struct. The reason being the 3 CD in the middle. The struct might look something like

struct (or class)
{
int n;
char c;
...
};

where the n is 26691400 in this case. Does that number fit in somewhere? Like a database table index or similar? There are a lot of hints if you know how to read and interpret them.

home

Frank Seidler

You can set a breakpoint when the memory is allocated. Take the number in curly braces and set it like this: _crtBreakAlloc = 159399; The debugger will break in, when the n-th memory block is allocated. see: http://msdn.microsoft.com/en-us/library/w2fhc9a3%28VS.80%29.aspx Regards Frank

Chris Losinger

see _crtBreakAlloc[^] basically, add this line to the very start of your program:

_crtBreakAlloc(159399);

then, when the CRT does its 159399th allocation, it will break (like an assert) and you can look at the stack to see who requested the allocation.

image processing toolkits | batch image processing

chen shi

#define new DEBUG_NEW add this line to the beginning of source files witch you suspect leaking memory. then the report will have file name and line numbers. :) (sorry for my poor english.)