On Thu, Jun 10, 2010 at 1:41 PM, Greg Parker <[email protected]> wrote:
> If you suspect a use-after-free bug somewhere, and NSZombie doesn't find it,
> then try this:
> 1. Verify that NSZombie is operating. Add `[[[[NSMutableString alloc] init]
> release] release]` to your code. Make sure NSZombie catches it.
Well, the simple test works: adding a deliberate over-release to my
applicationDidFinishLaunching: logs exactly the console message I'd
expect. And with a breakpoint on objc_exception_throw(), stops right
there.
With the actual crash, I get the stack trace I posted before, and no
expected console log. (I also tried turning the scribble off, and
disabling the breakpoint, just to see.)
> 2. If NSZombie doesn't help, try Guard Malloc. It's slow, but catches errors
> that NSZombie does not catch.
Enabline Guard Malloc and running the app, it crashes in exactly the
same way, but the stack trace has slightly more information; the ?? is
replaced with an actual method (but still in framework code):
#0 0x91a27ed7 in objc_msgSend
#1 0x04ba6b20 in -[_PFManagedObjectReferenceQueue
_processReferenceQueue]
#2 0x01dc89ba in _performRunLoopAction
(Just for grins, I turned off zombies and malloc logging, and tried
again, and got the same result.)
Sixten
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
