> > Any advice on how to go about finding this leak? > In the public method of this component you could compare the number of > memory handles - SYS(1011) - at the beginning and the end of each method > call.
Thanks for the reply. Unfortunately, the OO-aspect of the code made this a little difficult to be useful. It showed bloat over the lifetime of the whole object, yes, but that didn't help track it down. The problem, as I suspected, ended up being a binding reference/deadly embrace situation. There was one object that was typically a property of one object, and it got destroyed properly on destruction of the entire heirarchy. I hadn't realized that there was two spots, however, that used the object inline/on the stack as a local object, and the Release() method was never called to clean it up properly... Adding the release() for these local objects fixed the leak. In retrospect, thinking about the best way to find this kind of problem, it seems some sort of 'object registry' where in the init of each class, some code executes to 'register' it in a table/data structure of some sorts(class, unique ID, and the call stack), and in the destroy it marks it as 'destroyed'. When done running, any objects that weren't destroyed properly will have entries without the 'destroyed' flag set... If I have this sort of problem again, I'll build a quick debugging class to handle this for me. -- Derek _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
