On Dec 23, 2008, at 12:23 AM, Rob Keniger wrote:
#0 0x96928cd0 in __CFTypeCollectionRelease ()
#1 0x968b5ad6 in CFArrayApplyFunction ()
#2 0x968b93fc in __CFArrayDeallocate ()
#3 0x90798f31 in -[NSCFArray finalize] ()
#4 0x92ba86b6 in finalizeOneObject ()
First, a question: is it always an NSCFArray that is crashing during
finalization? Or does the object vary?
If this were retain/release, that'd be an obvious over-release.
With GC, this typically comes up because some object in the array has
been trashed. That is, there is a memory corruption bug.
You can try running with libgmalloc, but it sounds like the problem is
intermittent enough to be hard to reproduce.
Obviously, knowing what array is crashing will help. You might be
able to set a breakpoint on NSCFArray's finalize and then add a script
to the breakpoint that po's the object.
Something like (you'll have to paste then in one line at a time into
the debugging console or GDB will get cranky):
b -[NSCFArray finalize]
command
po *(void**)($ebp+8)
continue
end
It may be that the po is too much information or may cause crashes.
If so, change it to just 'p'. That'll spew the address. With
address in hand you can then use 'info malloc' to grab the backtrace
where the object was allocated, thus giving you a clue as to where the
array is coming from.
I really ought to write this up along with a few other debugging
tricks and turn it into a post on my weblog so Google more readily
indexes it....
b.bum
_______________________________________________
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
