Re: NSZombieEnabled giving rise to new bug
Re: NSZombieEnabled giving rise to new bug
- Subject: Re: NSZombieEnabled giving rise to new bug
- From: Wyatt Webb <email@hidden>
- Date: Mon, 12 Oct 2009 14:37:09 -0700
On Oct 12, 2009, at 9:01 AM, Bill Bumgarner wrote:
On Oct 12, 2009, at 8:50 AM, Nick Rogers wrote:
2009-10-12 20:28:53.651 My Program[33987:6263] *** -[CFArray
count]: message sent to deallocated instance 0x1149a9310
[Switching to process 33987]
[Switching to process 33987]
sharedlibrary apply-load-rules all
2009-10-12 20:29:03.917 My Program[33987:6263] *** NSInvocation:
warning: object 0x1149a9310 of class '_NSZombie_CFArray' does not
implement methodSignatureForSelector: -- trouble ahead
2009-10-12 20:29:03.918 My Program[33987:6263] *** NSInvocation:
warning: object 0x1149a9310 of class '_NSZombie_CFArray' does not
implement doesNotRecognizeSelector: -- abort
kill
quit
The code is so complex and its also hard to reach the point where
I'm doing the wrong -[CFArray count].
Is it possible to some how to get it automatically stop at [CFArray
count] OR is it possible to set a breakpoint at all [CFArray count]
in Xcode or in .gdbinit.
That won't necessarily help you. By the time the -count message is
sent the damage was done long ago. Zombies help by giving you the
address of the object that went bad earlier. What you need to
examine are all of the retain/release events that occurred at that
address prior.
To do this, you can use the ObjectAlloc Instrument in Instruments.
Turn on Zombie tracking and then have a look at the zombie object's
address in the instrument.
There are cases, though, where Instruments won't work for this. In
that case, set the MallocStackLoggingNoCompact environment variable
to 1 and then run your application. When you find the 'message sent
to deallocated instance' address, use 'malloc_history PID ADDR' at
the command line to see a history of all events at that address.
Or, in gdb, 'info malloc ADDR'.
b.bum
I just watched a WWDC 2009 video that talked about the new Zombies
instrument with Xcode 3.2. If you run with that instrument, it will
stop as soon as the message is sent to the bad address. Even better,
though, you can look at the address and see the entire retain/release/
autorelease history including call stacks for each entry. I haven't
used it, yet, but it looks like exactly what you need.
Wyatt
_______________________________________________
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