Advertisement

finding memory leaks

Started by February 25, 2000 01:14 PM
9 comments, last by Ridcully 24 years, 8 months ago
how can i find memory leaks my application creates by not freeing data? i am using visual studio 5 and found no way to do that. do you need a special program? i am not quite sure if my app creates leaks, but i would really like to know it...
There are some commercial programs that do that, but if you just want to find out if you have a leak you don''t need to bother.

First impulse of a way to check if you have memory leaks is to get the free memory starting your program, and the free memory ending the program. My first 3d engine, I also had free memory displayed in the top right corner of every frame in debug. If that number went down as the program executed I had a leak.
Of course with multitasking windows, this isn''t really viable because you never know when other applications are sucking up memory unexpectedly, but if you''re in DOS, why not?

Otherwise, you can track every allocation and deallocation and see if memory isn''t being freed. ClanLib, which has source code available, has a memory debug mode like this. At least in the 2.0 source tree.
Advertisement
In VC++ 6 the debugger prints some data from every undeleted memory at the end of a session. I use this by placing a DWORD in every class. In the constructor of the class I set this DWORD member to four characters that identify the type of class. This makes it really easy to find what classes and structures don''t get deleted. I don''t remember if this feature exists in VC5 though.

Or, as SiCrane, specified you can track the memory during a run. But instead of checking for free memory it would be better to check the amount of memory you have allocated, if this goes up uncontrolable you have a memory leak. The advantage of this is that it doesn''t care what other applications do.

quote: Original post by Spellbound
Or, as SiCrane, specified you can track the memory during a run. But instead of checking for free memory it would be better to check the amount of memory you have allocated, if this goes up uncontrolable you have a memory leak. The advantage of this is that it doesn''t care what other applications do.


Um isn''t that what I suggested at the end of my post? Not critisizing, but wondering if I was being clear.
use _CrtSetAllocHook to set a function which is called whenever memory is allocated, so you figure out where all your memory is being allocated.

and then _CrtDumpMemoryLeaks to dump all the allocations which haven''t been freed.

In fact it''s usually more useful to do this in the reverse order.....do_CrtDumpMemoryLeaks to find out the size of the allocations not freed...then in your hook function put a break point in if the malloc is that size...


Danack@codemasters.com

I made it a habit of every time a write a malloc/new line of code, I also write a free/delete line down where I expect it to happen. That way I never forget.

I also look out for what Spellbound mentions about VC++ giving warnings if it detects allocated memory blocks after the program completes.
Mike Weldon, a.k.a. FalloutBoymweldon@san.rr.com
Advertisement
SiCrane:
I''m sorry, my mistake. I thought I remembered an easier way to check how much memory the program had allocated. Sort of like GetFreeSpace() but returning amount of allocated memory instead. I checked now, but no, it didn''t exist. Again, I''m sorry if I stepped on your toes.

The best way to check for allocated memory would be to do the counting yourself, as you suggested.

But I think we have both been outsmarted though, by Danack. (Why not register Danack). The way he describes it is the best way to find memory leaks, in my humble opinion. (I learn something today as well, this really is a good place to hang out )
I''ve got two questions.

1. First of all, is there any way to hook up the _crt functions with new and delete ?

2. Secondly, I usually have problems if I use the _crt functions across DLLs. Lets say I have char *, declared in the DLL. Everything works fine if all the memory operations are handled by the DLL or the EXE exclusively.
So I get no error or leaks if the DLL passes the pointer to the exe for allocation, and the exe deletes it on exit as well.
However take this scenario.
The DLL passes it to the EXE for initial allocation.
It need to change the string during runtime, so it frees it, then reallocs it.
And then the EXE deletes it on exit.
I get a leak and this message.
Assertion failed: _CrtIsValidHeapPointer(pUserData)

I know I am probably missing something very obvious here. But I would appreciate any tips.

Thanks.
1. The hook functions should work automatically as new and delete use malloc and free internally.

2. You ARE missing something very obvious. You shouldn''t free the memory before calling realloc, as that returns the memory to the heap,
>_CrtIsValidHeapPointer(pUserData)
Yep, cause its already been freed once by your program.

Danack


Game production:
Good, quick, cheap: Choose two.
Game production:Good, quick, cheap: Choose two.
1.
Yes, but unlike _malloc_dbg_ , new doesn''t provide any detailed information. _malloc_dbg gives the filename and the line number where the memory was allocated. Something like that would be helpful.

2.
Whoops, bad explanation there.
I meant reallocation as in the noun. Not the memory function.

I am manually freeing the variable then MALLOC''ing again and copying over the new string data. Thats when I get that error.

Here is what happens again.

//lets take the following as the object

class MyVar
{
public: char * string;
};


//in the dll
MyVar * blah=0;
RegisterVar(&blah);

RegisterVar() is a functions exported by the exe. It allocs the variable, and puts something in string. I get no problems if I leave this as it is. The Exe deletes all the registered MyVar pointers on exit. The Dll doesn''t have to do anything.
However take this scenario, executed after the variable has been registered.

free(blah->string);
string = new char[20];
strcpy(blah->string,"test");

I do get a memory leak in this case.

This topic is closed to new replies.

Advertisement