Re: Best way to debug (was retain/release/pointers question)
Re: Best way to debug (was retain/release/pointers question)
- Subject: Re: Best way to debug (was retain/release/pointers question)
- From: Keith Blount <email@hidden>
- Date: Sun, 5 Dec 2004 11:26:02 -0800 (PST)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Thank you both for your replies, I really appreciate
the help - sorry the question was a little off-topic.
Anyway, using what you told me and by setting
NSZombieEnabled to YES, I finally tracked down my bug
- it took me about two days, and I'm not entirely sure
how to fix it (that's for another thread...:) ), but
at least I know exactly what it is now.
So many thanks again,
Keith
--- "M. Uli Kusterer" <email@hidden>
wrote:
> At 21:33 Uhr -0500 04.12.2004, Jonathan Jackel
> wrote:
> >This topic is probably more appropriate for the
> XCode list, and
> >you'll likely get better responses there, but as
> nearly everyone
> >here uses XCode, it's not insanely off-topic.
> >
> >Basically the debugger window breaks down into
> three panes. There's
> >a "thread" view in the upper left, a "variable"
> view at the upper
> >right, and the editor at the bottom.
>
> Note that you can customize the arrangement of the
> panes a little,
> so if it isn't that way on your computer, blame
> yourself ;-)
>
> >When your code stops on -[NSException raise] (BTW,
> you need that -
> >or + at the begining when you create a symbolic
> breakpoint),
>
> No you don't.
>
> (gdb) fb [NSException raise]
>
> works just fine for me.
>
> >You'll also see a lot of greyed out methods --
> those are methods
> >from the Cocoa frameworks that you cannot look at
> with the debugger.
>
> Well, you can, but you'll only get source code
> disassembly, which
> isn't half as much fun as getting the ObjC source
> code that this is
> equivalent to. But still, it can be quite
> educational.
>
> >If you click on one of non-greyed methods, the
> debugger editor will
> >show you exactly where in that method execution was
> stopped. Start
> >with the method at the top of the list and work
> your way down. As
> >you do this, examine the relevant variables in the
> variable view.
> >Usually this procedure (perhaps augmented with a
> few strategically
> >placed additional breakpoints) provides enough
> information to figure
> >out what's going on and fix it.
>
> Of course, if it's a memory bug, e.g. you've
> accessed an object
> after you've released it, the actual point where
> your app breaks may
> be a long time after your actual mistake. E.g. when
> you prematurely
> release an object in applicationDidFinishLaunching:,
> and don't access
> it again until applicationWillTerminate:, your app
> will run just fine
> and crash when it quits, even though the actual
> error happened
> immediately after startup. That's why memory bugs
> are so hard to
> track down.
>
> >The core of the debugger is gdb -- XCode is
> basically a GUI for it.
> >You can find out more information than you'd ever
> want to know by
> >typing "man gdb" in the Terminal.
>
> And then quite a bit more :-p
>
> --
> Cheers,
> M. Uli Kusterer
>
------------------------------------------------------------
> "The Witnesses of TeachText are
> everywhere..."
> http://www.zathras.de
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden