Looking for Memory Leak Advice

[Complete]

Apart from buying BoundsChecker or any of the other tools to track down memory leaks. Does anyone have any advice or tips from your years of programming experience to offer on how to track down the causes of memory leaks?

I find that the big dump that happens at the end of a program does not typically lend any useful clues as to where or what was allocated that was not freed. I find that I have to back track and comment out sections of code until through the process of elimination and trial-and-error, I am able to narrow down where the problem is. And since this is usually at the bottom of the To-Do list, the memory leaks are not plugged.

[jonnin]

if the program is interactive, you can bring up a tool like the task manager in windows or top in unix and try to see if some sequence of steps takes a chunk of memory. You can also watch it and see if it happens regularly like every 10 seconds or whatnot.

If the leak is large, look for large allocations (maybe do a search on every new statement in the program and look for new blah[100000] or the like). If it is small, you can try the reverse and look for a function that is called a lot, maybe a function that returns a pointer as these can be written such that the caller must deallocate...

If all else fails you can try to match every new to a delete statement, with a script or the like, and at least eliminate some of the possibilities and highlight things to check. If the programmers play swicharoo with pointers everywhere (x = y, ... delete y, x is also deleted sort of games) then this will not work. If most of the code is sane, it will.

[Danny]

BoundsCcheker and many other memory diagnostics tools often have false alarms, i.e., they report memory leaks that aren't really leaks. The best thing to do is reduce the amount of manual memory allocation in your programs and use standard containers instead. It's a very general piece of advice. If you can provide more details about the nature of your application, which memory management policy it uses etc., I'll be able to give more pinpointed guidelines. The bottom line is this: better design is tremendously more helpful than using memory leak detectors.

[Complete]

I have learned that you need to have a

CoUnitialize()

to go along with every

CoInitailze(0)

I wonder if I need something to go along with my

CoCreateInstance

calls.

[jonnin]

possibly -- you will have to look at the documentation or if you have none, try it in a stub program and see if that is a leak?

[Viorel]

. . .
I wonder if I need something to go along with my

CoCreateInstance

calls.

After you do not more need the object created with CoCreateInstance, I think you have to free it by calling Release function:

SomeObject * object;
CoCreateInstance(. . ., &object);
. . .
object->Release();

I hope this makes sense.

[Peter_APIIT]

Every new should has one delete.

Be aware of transfer ownership to another during passing arguments.

I hope this help.