Date: 2/6/2004
| The big problem with coding in general is tracking and debugging memory and resources. If you can be sure that an object is allocated and freed correctly, and then not accessed after it's freed you are a long way towards stability.
A long time ago someone mentioned on email that an Lgi application would eventually use up all the GDI resources and either crash or just display everything in black and white.
So I decided to look into this and so I jumped on google and hunted around for some tool to track GDI resources and tell me where the leaks are. Anyway all of them were either too expensive or didn't work so that was a dead end.
Well what self respecting coder can't "roll his own"? So I wrote a little tracker module that redirected all the GDI subsystem allocation and free calls through my own API. And then track the handles being used by the application. This took a few hours but this morning I got the results I needed. Indeed the application was leaking handles. And mostly because I was freeing a HDC before selecting the original brushes and pens back into it.
So now Lgi has an optional module for tracking GDI handles. It works by tracking each handle during runtime, and then dumping out a list of unfreed handles with the file/line number of the allocating source when the program exits using the Visual C++ debug console. Runtime performance is mildly affected but it's still pretty fast, maybe 60% of full speed. Which is still very usable.
I don't think this will affect the general stability of Scribe, but it should mean you can run it for longer and use less resources.
I've also been leak testing the general memory usage as well, and thats showing a lot of improvement. On Linux I was seeing footprint size increases of 80MB an hour or so. Now it's growing by a few MB an hour instead. Still not perfect but a little more reasonable eh!
|
