NSZombieEnabled

NSZombieEnabled

last edited August 27,2011 11:40:04 (96.251.87.19)
CocoaDev is sponsored by: Panic: Shockingly good Mac software!

Edit / History / New / Search     

Quick links: Home / Recent Changes / Jobs / Forums / Help

NOTE: ConsIDer using Instruments's ZombIEs template instead, as it gives you more information (particularly on what caused the object to be zombifIEd).

NSZombieEnabled is an environment variable which controls whether the Foundation runtime will use zombIEs. When zombIEs are enabled,a deallocated object's class is dynamically changed to be _NSZombIE,and by default,the memory region is never marked as free,although this can be controlled separately.

The end result is that,with zombIEs enabled,messages to deallocated objects will no longer behave strangely or crash in difficult-to-understand ways,but will instead log a message and dIE in a predictable and deBUGger-breakpointable way. This is the tool to use when trying to track down over-releases and premature releases.

ZombIEs will take effect for all Objective-C objects that are deallocated through normal means,including most Cocoa classes as well as user-created classes. On 10.4 and earlIEr,a rather important exception to this is most/all TollFreeBridged classes,as they are deallocated using CoreFoundation which NSZombieEnabled will not trap,in which case CFZombie must be used. On 10.5,NSZombieEnabled will work for TollFreeBridged classes as well.

See the CFZombie page for information on how to deBUG errors involving TollFreeBridged classes such as NSCFString.

For more information on this and other helpful deBUGging aIDs read

/System/library/Frameworks/Foundation.framework/headers/NSDebug.h

Use in Xcode:

NSZombieEnabled should not be left in place permanently,as by default no objects will ever be truly deallocated,making your application use tremendous amounts of memory. If you find yourself needing to use it often,you can create a second executable in your project which uses NSZombieEnabled so that you can easily switch between them. Do this by right-clicking the original executable,selecting "Duplicate",and then setting up NSZombie in the new executable.

Or,you can not use Xcode and instead run your application from the terminal,with the command:

env NSZombieEnabled=YES Whatever.app/Contents/MacOS/Whatever

Which will set the variable and run your application. (Substitue in your app's name for "Whatever",of course)

If you use this from time to time,you might want to add a check someplace like applicationDIDFinishLaunching,to alert you via the log whenever this option is on. That way you will avoID getting egg all over your face like I dID,after spending hours trying to find my memory leaks :-)

if(

getenv("NSZombieEnabled") || getenv("NSautoreleaseFreedobjectCheckEnabled")

) {

@L_502_28@(@"NSZombieEnabled/NSautoreleaseFreedobjectCheckEnabled enabled!");

}

Here is a List of break points to put in ~/.gdbinit that are really helpful in deBUGging memory problems:

fb -[NSException raise]

fb -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:]

fb -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]

#@R_419_5552@ NSZombIEs

# this will give you help messages.  Set to NO to turn them off.

set env MallocHelp=YES

# might also be set in launch arguments.

set env NSZombieEnabled=YES

set env NSDeallocateZombIEs=NO

set env MallocCheckHeapEach=100000

set env MallocCheckHeapStart=100000

set env MallocScribble=YES

set env MallocguardEdges=YES

set env MallocCheckHeapAbort=1

set env CFZombie 5

fb -[_NSZombIE init]

fb -[_NSZombIE retainCount]

fb -[_NSZombIE retain]

fb -[_NSZombIE release]

fb -[_NSZombIE autorelease]

fb -[_NSZombIE methodSignatureForSelector:]

fb -[_NSZombIE respondsToSelector:]

fb -[_NSZombIE forwardInvocation:]

fb -[_NSZombIE class]

fb -[_NSZombIE dealloc]

fb szone_error

-- AdhamhFindlay

Edit / History / New / Search     

Quick links: Home / Recent Changes / Jobs / Forums / Help