![]() | Blog |
![]() | Releases |
Gdi Resources | |
---|---|
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! |
(0) Comments | Add Comment | |
BeOS file handle state | |
---|---|
Date: 1/6/2004 | I'm working on porting the process handler class of Lgi to BeOS and I'm wondering how to get state information out of the file handles that are connected to the stdin and stdout of the process that is spawned by the class. i.e.
int s[2], pid; pipe(s); if (!(pid = fork())) { // stdout -> Read close(1); dup(s[1]); close(s[0]); // setup read & write handles execv(Exe, Args); } while (!exited(pid)) { // read from pid's stdout... IF there is data // available. On linux you can use poll }Anyone know an equivilant way to find out whether there is data on the handle to read? If I can fix this I can get my Ide working on BeOS and be twice as productive. i.e. more BeOS releases sooner. |
(0) Comments | Add Comment | |
Blog UI | |
---|---|
Date: 1/6/2004 | I've fixed the little calendar on the sidebar to actually have working navigation links. So that you can scroll through historical blog entries.
Yes when I get sick of C++ I play with PHP :) |
(0) Comments | Add Comment | |
i.Ftp ala Linux | |
---|---|
Date: 28/5/2004 | Yes the unholy trinity is here! i.Ftp on Linux joins the Win32 and BeOS build's to make the first simultaneous release on 3 platforms!
Make your time! |
(0) Comments | Add Comment | |
i.Ftp v1.82.... BeOS-Zeta Release | |
---|---|
Date: 27/5/2004 | Yes thine eyes do not deceive you, there is a new BeOS binary on MemeCode after all these years. The app that lived first on BeOS r5 now lives again. Behold i.Ftp for BeOS!
And shortly a Linux build will magically appear, completing for the first time in history a tri-platform release for MemeCode. Windows, Linux and BeOS. Oh happy day! |
(0) Comments | Add Comment | |
Scribe | |
---|---|
Date: 25/5/2004 | From the feedback I've been getting it appears that the 100% CPU hang in Scribe has indeed been fixed in the most recent test build. On top of that the other major showstopper: not being able to reliably send to multiple recipients bug also has a possible fix in place. So all in all I'm feeling like I'm getting on top of the bug situation with Scribe and my todo list has a whole lot less critical things on it now than for most of the year.
The hang bug was caused by a incorrect error code returned by windows. Which confused the threading code such that the thread would start executing but the owning object would think that it had failed to start. So you can imagine the sort of confusion that would ensue. I'm learning not to trust the windows error codes the hard way. It seems obvious in hindsight, but everything always is. *sigh* |
(0) Comments | Add Comment | |