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: Thu, 29 Nov 2007 22:21:29 +0100

Hi,
Richard Frith-Macdonald <richard@tiptree.demon.co.uk> wrote: 
> On 2007-11-28 19:45:40 +0000 "Sebastian Reitenbach" 
> <sebastia@l00-bugdead-prods.de> wrote:
> 
> > Hi,
> > 
> > Richard Frith-Macdonald <richard@tiptree.demon.co.uk> wrote:
> >> On 2007-11-27 16:40:36 +0000 "Sebastian Reitenbach" 
> >> 1<sebastia@l00-bugdead-prods.de> wrote:
> >> 
> > 
> > 
> >> 
> >>> 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.
> > I added that enableDoubleReleaseCheck directly in the method, after 
> > the 
> > allocation of the NSAutoreleasepool, but that ended in an exception. 
> > Where 
> > would be the correct place to enable that?
> 
> It needs to be enabled before the creation of any object which might 
> be in the autorelease pool causing a crash.
> Unless you have a really clear knwledge of the object lifetimes 
> involved, that probably means you should do it right at the start of 
> your program in the main() function.
ah, then I was definitly at the wrong location, will add it in the main,
and see what happens.

> 
> >> 
> >> 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.
> > I set these environment variables, and also started the ogo-webui-1.1 
> > -NSDebugEnabled YES -NSZombieEnabled YES -NSDeallocateZombies YES 
> > -WOUseWatchDog NO
> > I searched a bit around, and found this:
> > http://www.cocoabuilder.com/archive/message/cocoa/2003/9/14/87250
> > I also explicitly #include <Foundation/NSDebug.h>
> > 
> > but I did not observed any changes? What should I expect to see with 
> > these 
> > enabled?
> 
> Well, NSDebugEnabled should do nothing as far as I recall it's not an 
> option GNUstep uses.
> 
> NSZombieEnabled=YES should turn on zombies ... so deallocated objects 
> remain allocated and you get a report printed when anything tries to 
> send a message to them.
I haven't seen anything, but I'll retry and see.

> 
> NSDeallocateZombies=YES stops the zombie objects remaining allocated, 
> so you probably want NSDeallocateZombies=NO
ah, yeah, I also thought that, tried that too, but haven't seen a difference 
when it comes to the crashers

> 
> Including Foundation/NSDebug.h does nothing unless you change your 
> code to use the functions and macros declared in it.
I only included that file, because I haven't seen anything from the above
, that I thought, it might help me in one way or another.

thanks a lot for the information.
I hope I get a bit forward with that.

Sebastian
> 
> 
> 





reply via email to

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