Re: trying to debug problems with NSAutoreleasepool

[Sebastian Reitenbach]

Richard Frith-Macdonald <richard@tiptree.demon.co.uk> wrote: 
> On 2007-11-27 16:40:36 +0000 "Sebastian Reitenbach" 
> <sebastia@l00-bugdead-prods.de> wrote:
> 
> >> 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.
thanks a lot for these hints, I'll see how far I get with these.

Sebastian