Detecting memory leaks in C++.

dave13

There are leaks in my program. When i use _CrtDumpMemoryLeaks(); and debug i get this
Detected memory leaks!
Dumping objects ->
{51} normal block at 0x00D01B20, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{50} normal block at 0x00D00040, 40 bytes long.
Data: < |L > 14 7C 4C 10 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.

The thing is i can't find out where these leaks are occuring. According to MSDN i t should return line numbers. Anyone have any ideas?

Khannie

There are plenty of tools out there for detecting memory leaks for you.

Are you running windows or linux?

Windows = rational purify
can't remember the name of the linux one, but it's top notch. If you're running linux I'll go digging for you.

edit: Valgrind. Quality stuff.

daymobrew

When I was debugging an app, the debugger never gave line numbers, but, IIRC, it did name the object (CString etc) that was the problem.

Do you have any objects with 'C' or '|L' in them?
Are there any points in your code where you create something dynamically?

bringitdown

Purify is the grand-daddy and an absolute brilliant tool. However it is very expensive to license.

Electric Fence (*NIX, Some Windows Support):
http://freshmeat.net/projects/efence/

Bounded Pointer version of GCC:
http://gcc.gnu.org/projects/bp/main.html

Interesting thread on (Ask)Slashdot:
http://slashdot.org/askslashdot/01/08/09/1245235.shtml

You seem to be using VC++ tho - is this a win specific app?
http://www.codeproject.com/debug/consoleleak.asp
Is an example of how to get the line numbers from _CrtDumpMemoryLeaks

theexis

wonderboy wrote:

The thing is i can't find out where these leaks are occuring. According to MSDN i t should return line numbers. Anyone have any ideas?

Couple of things you should do.

1. In your precompiled header, add the following (assuming you want to catch leaks during debug only...). This should come before any includes that could pull in crtdbg.h etc.

#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#endif

2. In each cpp file you need to define a macro that overrides the new call to so file/line info is tracked

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

3. Optionally you could enabled more detailed tracking during you app startup, but this could seriously slow down your debug app execution speed:

#ifdef _DEBUG
		_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF |  _CRTDBG_CHECK_ALWAYS_DF);
	#endif

dave13

After using the code in the codeproject link my error messages are now
Detected memory leaks!
Dumping objects ->
{54} normal block at 0x00C81960, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{53} normal block at 0x00C819B0, 40 bytes long.
Data: < |L > 14 7C 4C 10 16 00 00 00 00 00 00 00 00 00 00 00
{46} client block at 0x00C80030, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $00C80030, 64 bytes long
Object dump complete.
Anyone know what this means?Me and C++ are not good friends.

theexis i tried your method but i'm getting errors. Where do i put them. I pretty much have one cpp file.Do i put them in the global part, in the main or in a running thread?

theexis

Are you talking about compile errors? Could you post them?

From the additional leak, I'm guessing either your project is compiled to a DLL, or its using a DLL and the leaks are coming from within it. For a simple 1 file cpp the file would be something like:

#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#endif

#include <crtdbg.h>

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

void main(void)
{
    char* px = new char[50];
}

Running this minimalistic app should give you an accurate leak detection for char* px within a debug build.

I'm not 100% sure what you mean about threading since all this is compile time effectively.

dave13

Got your code working but the debug output is still the same.
Detected memory leaks!
Dumping objects ->
{54} normal block at 0x00C819F0, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{53} normal block at 0x00C81A40, 40 bytes long.
Data: < |L > 14 7C 4C 10 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.
The thread 0xA20 has exited with code 0 (0x0).
Detected memory leaks!
Dumping objects ->
{54} normal block at 0x00C819F0, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{53} normal block at 0x00C81A40, 40 bytes long.
Data: < |L > 14 7C 4C 10 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.

It still doesn't give any line numbers and i can't see what could be causing memory leaks.I don't have any new declarations in my code.However if i deliberately introduce a memory leak it prints out the offending line.Whats happening?

theexis

Ok, that points to the leak being outside of the module you're compiling then - are you referencing any DLLs (as I mentioned above, you seem to be leaking a DLL type object in your trace, so that means memory leaks within the DLL: in order to get line numbers you'd need to do the same to the DLL source files).