Finding Memory Leaks

buuck · Nov 17th 2012, 12:35pm

I'm using the _CrtSetDbgFlag() function like in the sample code to look for memory leaks, and I'm finding some in the tests that I'm writing. At the end of the program, the following is printed in the output box of VS:

Source Code

Detected memory leaks!
Dumping objects ->
c:\users\phillaptop\desktop\game engines\gccremake\src\gccremake\gccremake.cpp(19) : {152} normal block at 0x00C1BE38, 12 bytes long.
Data: <\; 7)@ > 5C 3B D6 00 17 37 29 40 07 00 00 00
Object dump complete.

Where should I go from here? Is there a way in VS to determine what is being held at memory location 0x00C1BE38?

I uncommented all three of the values that are in the sample code, so it's running the maximum amount of checks.

buuck · Nov 17th 2012, 12:47pm

I guess I jumped the gun, because I just figured out what's going on.

In the equivalent to my TeapotGameLogic::VCreateGameandView(), when I dynamically create the game logic, apparently this is never being released. I tried releasing it in a destructor for my ~GameApp(), but it still says this object is unreleased. Any ideas on what to do here?

EDIT: Nevermind this whole thread. My destructor for GameApp() wasn't virtual, so it wasn't being called. All is good now. I hope someone finds this self-solving helpful!

rezination · Nov 17th 2012, 12:58pm

I don't really like the CRT memory leak tools because they tend to be fairly cryptic. I use VLD (Visual Leak Detector). To use it, you simply include the vld.h header at the top of your program and make sure the appropriate DLL is in your working path. VLD will dump the call stack for the allocation of eacfh memory leak it finds. You can even double-click on one of those lines to jump right to it. This makes finding and fixing memory leaks MUCH easier.

Just google for "vld" and you should find it.

-Rez

mholley519 · Nov 17th 2012, 2:55pm

When you use the CRT Debug library you redefine the new keyword to add extra data, the file name and the line number.

This here says, in the file gccremake.cpp at line number 19 there is a 12 byte memory leak that you are not deleting, if you ever come across a memory leak which does not use the redefined new keyword, it will still show the leak but without having the location. I found that the STL string class causes issues like this, it's best to ignore these as long as it is part of the STL and not your project.

However in this case just make sure you are deleting whatever you allocate on line 19 (Or if it is a shared_ptr make sure you are not holding onto any references anywhere)

buuck · Nov 19th 2012, 1:10pm

Wow, you're right Rez, VLD is a much better alternative! Thanks for the suggestion.

kaykry · Nov 29th 2012, 10:45am

Originally posted by rezination
VLD will dump the call stack for the allocation of eacfh memory leak it finds.

Nice one, just gave it a try. So far, so good.

questor/fused · Nov 30th 2012, 9:03am

when you know the bad allocation number (the one between {}) you can create an breakpoint when your application allocates the memory (assuming the app allocates the memory in the exact same order every run) with a call to _CrtSetBreakAlloc(xxx);

Source Code

Share