Re: Best way to debug (was retain/release/pointers question)

FROM : Keith Blount
DATE : Sun Dec 05 20:26:02 2004

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" <Witness.of.<email_removed>>
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