|
Sorry, yes of course you have. I turned up this post
which supports what Joar is saying:
It seems the only way forward is to somehow provoke the
crash with Zombies enabled. Or you could try the dreaded, glacial Guard
Malloc, although it's a shame it's so hopelessly slow.
MallocScribble might also be of some value:
But you probably know all this already so I'll shut up
now.
Regards,
Paul Sanders.
----- Original Message -----
Sent: Sunday, June 20, 2010 2:13 PM
Subject: Re: _NSZombie Breakpoints don't Resolve (Xcode
3.2.2)
On 2010 Jun 20,
at 03:03, Paul Sanders wrote:
> Have you tried setting breakpoints on
malloc_error_break and objc_exception_throw? You can do this from the
debugger console window (with the 'b' command) and doing so will not change the
behaviour of your application in the way that enabling zombies
does.
Thank you, Paul. Yes, I have set those breakpoints and,
depending on how the crash occurs, sometimes they break. But, in my brain,
that doesn't allow me to identify the dead object which received the message or
whatever, since it's already been overwritten. Hence enabling
zombies.
I'm still working on this, although currently on a slight
detour.
Regarding the screenshot in my first post, showing that
-[_NSZombie whatever] breakpoints always appear unresolved… Joar said that
these breakpoints are unnecessary today. Howevever, if you *do* set one of
those breakpoints like I did, is it expected behavior that they appear in Xcode
as unresolved?
That seems odd.
|