Strange Memory Leak

Started by
6 comments, last by marius1930 12 years, 10 months ago
Hi Folks,

I have a bit of a strange memory leak on my hands. I have added a data breakpoint into my application where my memory manager tells me I am leaking a relatively small amount of memory 24 bytes on application exit. This is occuring at a realloc call in _free_dbg_nolock function on dbgheap.c.

Now here is were it gets a bit strange as popping up the callstack I get to one of my application classes destructor. However all I am doing is asserting all variables are empty that pertain to the class. These asserts pass with flying colours meaning the class should be destructing without issue.

The class is a base class to my application which has multiple inheritance.What reasons are there for seeing this memory leak?

I am thinking my Application could in some way have gotten corrupted into thinking it should be releasing memory at this point when it shouldn't. I'm thinking perhaps the program counter is nerfed at some point??????

Also is there any way I can determine I am debugging against the correct symbols?


Any help or ideas of how to get to the root of this memory leak would be much appreciated.

Thanks,

Mark.
"I have more fingers in more pies than a leper at a bakery!"
Advertisement
Disable portions of your code until you narrow down where it's happening; if you can reproduce the issue in a small example, post the code here for examination.

Otherwise... it could be a million different things. It's anyone's guess as to which case(s) apply to you...

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

As ApochPiQ points out this could be any number of things, however one thing that springs to mind, check that your base class destructor is virtual.

Also is there any way I can determine I am debugging against the correct symbols?


Not the best method but you could compare the modified timestamp of the .pdb with that of the .exe
Data breakpoints are not an effective way to debug memory leaks. They show you when the memory location is being accessed, not when it's NOT being accessed.

The most straightforward way to debug memory leaks with the MSVC debug CRT is to (1) make your program deterministic enough, (2) grab the ID of the leaked allocation, then (3) tell the CRT to break on its allocation with _crtBreakAlloc.

My offhand guess is that you don't have a leak at all, the memory is being freed by something that runs after _CrtDumpMemoryLeaks, and that data breakpoint is showing you the debug heap writing garbage into the block on deallocation.
Thanks for all the great suggestions I'll post back here with more info and touch wood the solution.
"I have more fingers in more pies than a leper at a bakery!"

Data breakpoints are not an effective way to debug memory leaks. They show you when the memory location is being accessed, not when it's NOT being accessed.

The most straightforward way to debug memory leaks with the MSVC debug CRT is to (1) make your program deterministic enough, (2) grab the ID of the leaked allocation, then (3) tell the CRT to break on its allocation with _crtBreakAlloc.

My offhand guess is that you don't have a leak at all, the memory is being freed by something that runs after _CrtDumpMemoryLeaks, and that data breakpoint is showing you the debug heap writing garbage into the block on deallocation.


Looking into this issue further it appears you were spot on Sneftel. I am calling _CrtDumpMemoryLeaks before the debug heap clears this particular class up. Thanks everyone for your quick and thorough responses, chalk another one up to the gamedev.net community :)
"I have more fingers in more pies than a leper at a bakery!"
Should look into _CrtSetDbgFlag, handy for cases such as this one.

Perhaps something like:

#include <crtdbg.h>
#define new new( _NORMAL_BLOCK, __FILE__, __LINE__)
#pragma warning(disable : 4345)

_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)|_CRTDBG_LEAK_CHECK_DF);

This topic is closed to new replies.

Advertisement