Re: crash in initWithCoder
Re: crash in initWithCoder
- Subject: Re: crash in initWithCoder
- From: Greg Parker <email@hidden>
- Date: Tue, 15 Mar 2011 18:45:44 -0700
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 email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden