On 30 Nov 2006, at 09:30, Marc Brünink wrote:
Chris Vetter wrote:
On 2006-11-29 18:55:15 +0100 Marc Brünink <[EMAIL PROTECTED]>
wrote:
today I discovered a memory leak in one of our frameworks. I
searched till I went mad, but didn't find anything.
Has anyone a suggestion how to track this one down?
The easiest way would be to replace NSObject's -init and -dealloc
methods. The replacement of -init would then create a counter
object (if it doesn't exist yet) when ever it is called, and
increment it by one, then return the original -init. The new -
dealloc would just decrement the object counter by one, then call
the original -dealloc. To check, you would have to first swizzle
the original -init and -dealloc with the new ones, run your test,
dump the counter when its finished, then switch both methods back
to the original.
Yes, it's a hackish way, but it works.
Hi Chris,
I tried this one already. I wrote a MyObject and posed it as
NSObject. However NSArray for instance does not call [NSObject
alloc]. (??) Correct me if I'm wrong.
It calls +allocWithZone: ... if you are wanting to override object
allocation, this is a more fundamental method. More fundamental
still is the NSAllocateObject() function.
However, not all classes will call +allocWithZone: or even
NSAllocateObject(), though the vast majority do the former and
almost all the latter.
Anyway, unless you have a special need to override allocation/
deallocation for a particular class, I would recommend you use the
memory allocation debug functionality that GNUstep provides in
NSDebug.h instead. This gives you a whole lot of memory allocation
tracking options, from keeping overall counts of objects of each
class, right down to providing callbacks for each individual object
allocation/deallocation. Not only that, but it's hooked in to the
most fundamental object allocation/deallocation functions
(NSAllocateObject() and NSDeallocateObject()) as well as those few
cases where the GNUstep libraries don't use those fundamental
functions ... so it is much more exhaustive than just overriding
+allocWithZone:
If your framework is in a gui application, clicking on the icon in
the standard info panel should display the memory panel showing
allocated object counts ... this gives you a very easy to use
starting point for tracking leaks
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
