oops... How do I enable Guard Malloc in Xcode 4? J.
On 2011-03-15, at 6:45 PM, Greg Parker wrote: > On Mar 15, 2011, at 4:10 PM, James Maxwell wrote: >> I'm getting a crash in initWithCoder, which seems related to decoding a >> property called "value", which is of type id. Sometimes this object is an >> NSString, sometimes it's an NSNumber, and sometimes it's an NSArray. The >> crash only occurs in cases where "value" is an NSArray. The last few lines >> in my backtrace are: >> >> #0 0x963c4206 in szone_malloc_should_clear () >> #1 0x963c41a8 in malloc_zone_malloc () >> #2 0x94920a13 in _CFRuntimeCreateInstance () >> #3 0x94943482 in CFNumberCreate () >> #4 0x949586f2 in __CFBinaryPlistCreateObject2 () >> #5 0x94985fe0 in __CFBinaryPlistCreateObject () >> #6 0x9823eb11 in _decodeObjectBinary () >> #7 0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] () >> #8 0x98240981 in -[NSArray(NSArray) initWithCoder:] () >> #9 0x9823f508 in _decodeObjectBinary () >> #10 0x9823e800 in _decodeObject () >> #11 0x000cdf05 in -[CbCM_Node initWithCoder:] (self=0x4098770, >> _cmd=0x9433805c, aDecoder=0x410f1c0) at >> /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore >> Test Build/ManuScore/CbCM_Node.m:573 >> >> From this, I'm guessing that the problem is happening with one of the >> members of the "value" array. Does that seem right? (I should mention, >> though, that the trace isn't always the same...) >> I am retaining "value" when I decode it, so it's not a simple memory bug. I >> have also run the code with Zombies (NSZombieEnabled=YES), which doesn't >> indicate any Zombied objects. Finally, the analyzer sees no memory errors >> (there are a number of "dead stores" - mostly unused variables - but these >> aren't likely to be real problems, are they?), so I'm stumped. I'm running >> Xcode 4, btw. > > A crash inside malloc generally means that there's a memory error elsewhere > that corrupted malloc's data structures. (Actual bugs in malloc are rare.) > malloc may store information before or after each allocation, and inside > freed allocations. > > The usual bugs are: > * writing data before or after the bounds of an allocation. Usually this > comes from bounds errors in C arrays. > * writing data into an allocation after freeing it. > > NSZombie catches the latter for Objective-C objects. But if the problem is a > non-object allocation, or a bounds error, then NSZombie won't help. > > The next tool to try is Guard Malloc. It catches both of the above errors for > any malloc allocation. On the down side, it is slow and memory intensive, but > if this -initWithCoder: is running early in app launch then you won't have > any trouble with it. > > http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/guardmalloc.3.html > > > -- > Greg Parker gpar...@apple.com Runtime Wrangler > > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
