|
From: | Richard Frith-Macdonald |
Subject: | Re: trying to debug problems with NSAutoreleasepool |
Date: | Tue, 27 Nov 2007 17:29:10 +0000 |
User-agent: | GNUMail (Version 1.2.0) |
Perhaps you have objects in the poolthat are crashing when they are released?I think, that seems to be the case. but how do I find out what kind of objects that are? The webui segfaults with the backtrace above, when I think it is emptying the last object from the pool, not sure about that. I do not fully understand what is going on there.
Understandable ... the autorelease mechanism is pretty performance critical, so it works hard to be fast and sacrifices some readability for speed. While emptying a pool, the code caches method implementations to avoid having to do multiple method lookups for objects which are all of the same class. It caches the implementations in a tiny hash table based on the address of the class (shifted right a few bits to allow for the fact that classes tend to be aligned on 4 or 8 byte boundaries, so the low few bits are useless as a hash).
At least at ten places in opengroupware I commented out a [pool release]; or equivalent, to prevent these crashers.As I doubt, that commenting out these lines, is the right solution,
Almost certainly not ... that probably introduces a big memory leak.Most likely you have a problem with objects being released more times than they are retained.
You can call [NSObject enableDoubleReleaseCheck: YES]; to turn on some checking for this ... but it will slow down your code quite a bit.
You can set the environment variable NSZombieEnabled to YES ... which will give you diagnostics about any attempt to use a deallocated object, but will use lots of memory. You can also set NSDeallocateZombies to YES to avoid leaking memory as zombie objects, but this will give you less informative and less reliable (the memory from a deallocated object could have been re-used as another object) logging.
[Prev in Thread] | Current Thread | [Next in Thread] |