Re: Tracking a EXC_BAD_ACCESS when zombies don't work
Re: Tracking a EXC_BAD_ACCESS when zombies don't work
- Subject: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
- From: Keith Blount <email@hidden>
- Date: Wed, 16 Feb 2011 10:27:23 -0800 (PST)
Many thanks for the reply, Sean, much appreciated. Unfortunately still no joy, though. I had already tried setting the CFZombieLevel to 3 (and other values - sorry, I should have mentioned that), but according to the tech notes, since 10.5 Core Foundation types are covered by NSZombie anyway (which is probably why I couldn't find anything on CFZombieLevel newer than five years old), so I don't think adding CFZombieLevel is adding anything over NSZombieEnabled.
The "Hamster Emporium" (!) article looked hopeful, but unfortunately everything I've looked at seems to assume you can get some useful information from the console - either a selector name using NSZombies or a bad memory address - and then proceeds from there, and I'm getting neither. The console reports nothing more useful than this, no matter what I try:
tar(7728) malloc: stack logs being written into /tmp/stack-logs.7728.tar.XYgOka.index
tar(7728) malloc: stack logs deleted from /tmp/stack-logs.7728.tar.XYgOka.index
Program received signal: “EXC_BAD_ACCESS”.
(I have MallocStackLogging turned on as well as NSZombieEnabled.)
And the backtrace doesn't help either:
#261968 0x98d06f38 in CFRelease
#261969 0x98d06f38 in CFRelease
#261970 0x98d06f38 in CFRelease
#261971 0x98d33c6d in _CFAutoreleasePoolPop
#261972 0x9867d0aa in NSPopAutoreleasePool
#261973 0x9867cfd2 in -[NSAutoreleasePool drain]
#261974 0x986c4596 in _NSAppleEventManagerGenericHandler
#261975 0x91450f58 in aeDispatchAppleEvent
#261976 0x91450e57 in dispatchEventAndSendReply
#261977 0x91450d61 in aeProcessAppleEvent
#261978 0x9519d389 in AEProcessAppleEvent
#261979 0x93b9a9ca in _DPSNextEvent
#261980 0x93b99fce in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
#261981 0x93b5c247 in -[NSApplication run]
#261982 0x93b542d9 in NSApplicationMain
#261983 0x0003513a in main at main.m:23
(Those CFReleases at the top go on and on and on when they appear - other times they don't appear at all.)
And everything I turn up on EXC_BAD_ACCESS from searches just provides NSZombieEnabled as the answer (unsurprisingly given that it's always worked for me in the past, as I say).
I am still slowly working my way through every technique listed in the tech note you linked to, though, having gone through it and tried the obvious ones first.
Thanks again,
Keith
--- On Tue, 2/15/11, Sean McBride <email@hidden> wrote:
> From: Sean McBride <email@hidden>
> Subject: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
> To: "Keith Blount" <email@hidden>, email@hidden
> Date: Tuesday, February 15, 2011, 8:55 PM
> On Tue, 15 Feb 2011 12:41:51 -0800,
> Keith Blount said:
>
> >I'm trying to debug an EXC_BAD_ACCESS crash in my
> application and am
> >tearing my hair out trying to find the cause. I have
> NSZombieEnabled set
> >to YES, but this isn't providing me with any
> information (using
> >NSZombieEnabled is always one of the first things I try
> with crashes
> >like this one, and usually it leads to the culprit
> after a bit of work).
> >I've read that zombies don't always help find
> EXC_BAD_ACCESS (for
> >instance if a variable hasn't been initialised or if
> it's a CF type,
> >although I'm not sure if the latter is still true), so
> presumably this
> >is why it's returning nothing for me.
> >
> >So, all I have to go on is an EXC_BAD_ACCESS, and a
> backtrace that seems
> >to be different every time and usually contains none of
> my own methods.
> >For instance:
>
> Have you read:
>
> <http://developer.apple.com/library/mac/#technotes/tn2004/tn2124.html>
> specifically the CFZombie stuff?
>
> and
>
> <http://sealiesoftware.com/blog/archive/2008/09/22/
> objc_explain_So_you_crashed_in_objc_msgSend.html>
>
> Might help...
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng
> email@hidden
> Rogue Research
>
> www.rogue-research.com
> Mac Software Developer
> Montréal, Québec, Canada
>
>
>
_______________________________________________
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