|
| From: | Richard Frith-Macdonald |
| Subject: | Re: memory leak |
| Date: | Thu, 30 Nov 2006 10:00:39 +0000 |
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 <mbruen@smartsoft.de> 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
| [Prev in Thread] | Current Thread | [Next in Thread] |