discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trying to debug problems with NSAutoreleasepool


From: Sebastian Reitenbach
Subject: Re: trying to debug problems with NSAutoreleasepool
Date: Tue, 27 Nov 2007 18:43:17 +0100

Richard Frith-Macdonald <address@hidden> wrote: 
> On 2007-11-27 16:40:36 +0000 "Sebastian Reitenbach" 
> <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]