MSDN has a wonderful article this month (it's March already, right?) about detecting GDI leaks, along with a nice looking tool.
(Don't post questions to me, I'm just downloading these myself)
Resource Leaks: Detecting, Locating, and Repairing Your Leaky GDI Code
Download the code for this article: Leaks.exe (106KB)
Ernie,
I chuckle at gizmos to find leaks in GDI code, there has always
been a rule with GDI code which works like the law of gravity,
what goes up must come down. This means what you allocate, you
de-allocate and you !!!! TEST !!!! to make sure the resource IS
deallocated.
If you are still not sure that a procedure is leak free, put a
call to it in a loop and run it a few million times and see if
your available memory drops dramatically.
I am very much a fan of fixing code as you write it, not appealing
to some newfangled gizmo to find the messups after they have been
written. In the long haul code is developed a lot faster if you
get it reliable the first time and don't have to go back trying to
find where the bugs are.
Regards,
hutch@pbq.com.au
hutch,
Please save your chuckling until after you read the article. He seems to have done a nice job getting a COUNT of each resource type.
Yes, I know all the same GDI rules you do too. And I test my stuff frequently, usually added function by added function.
Which is to say nothing against another testing tool, one which may well catch a single resource gone astay a single time.
After all, most bugs don't present themselves in a nice convienent place like the main message loop. They only arise when the sun is down, your shoes are off, and the coke machine down the hall turns back on it's refridgeration unit. IE, a weird UNEXPECTED series of events.
And never forget in the classical sense the programmer is also a Godelian formal system.
Hey, thanks a lot for posting this. I have a problem with leaks before, and asked a question here, but nobody new.
I have really been looking for this for quite a while.
seeya, John