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: Jonathan Jackel <email@hidden>
- Date: Sat, 4 Dec 2004 21:33:20 -0500
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.
When your code stops on -[NSException raise] (BTW, you need that - or +
at the begining when you create a symbolic breakpoint), scroll through
the thread view. It lists the "call stack," which is all the methods
that are currently "active". If an object in ClassA has told an object
in ClassB to doSomethingWithThis:, the list will have -[ClassB
doSomethingWithThis:] -- probably somewhere near the top -- and the
calling method from Class A below that. Way down at the bottom is
main, which starts your program and remains active as long as it is
running.
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.
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.
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. You can enter gdb commands in the
debugging console in XCode, e.g., "po someString" prints the
description of the object called someString, provided the debugger is
stopped in a method where someString exists.
Hope that helps.
Jonathan
On Dec 4, 2004, at 2:16 PM, Keith Blount wrote:
Many thanks for your reply, much appreciated.
I am now utterly confused, as I am getting several
exceptions at runtime and have no idea what is causing
them. They only occur on rare occasions, and even
then, if I go back and do exactly the same thing to
try and reproduce them, they only seem to occur about
1 in every 10 attempts. They are usually of the
"selector not recognised" variety, but at other times
complain about a string being out of range in my text
view when nothing should have happened. Very strange.
I am therefore wondering what the best way of
debugging is - a very basic question, I know, but none
of the books I have seem to cover this in any depth
(Kochan covers it a little, Hillegass not at all,
barely anything in Anguish et al). Until now, I have
been relying on simple NSLog()s for all my debugging,
but I think I need something more thorough at this
stage - ie. I need to learn how to use the debugger
properly. I have searched the archives and as a result
gone to the Debug menu and added a breakpoint at
[NSException Raise], which stops my program when I get
an exception and provides me with lots of feedback -
but I don't know what to do with that feedback as it
is all either gobbledygook or lists of points in my
code, so that I don't know if one of those is the
problem, or all of them, or none of them.
Is there a good tutorial anywhere on how to understand
all the information in the debugger, or on how to use
the debugger to trace problems? (Eg. what is a
"backtrace"?) I've been looking through stuff about
the debugger in the docs but am still nonplussed.
Many thanks to anyone who can point me in the right
direction, and many apologies for what is probably to
most of you Cocoa experts a very remedial question.
Thank you,
Keith
--- Fabian Lidman <email@hidden> wrote:
SomeCusomView *aView = [[SomeCustomView alloc]
initWithFrame:aRect];
[anotherView addSubview:aView];
[aView release];
//...
[aView doThisOrThat];
Your assumptions are correct. Calling [anObject
release] the object
only actually releases when the retain count is 0.
It is not moved in
memory.
The fact that the runtime complains about a selector
not recognized
indicates that the object still 'lives' (otherwise
you'd probably get a
SIGBUS or something).
For debugging purposes, use NSLog(@"%d", [anObject
retainCount]); to
find out the current retain count of your object.
Clever use of autorelease and nested autorelease
pools can save you
some headache. Read Apple's documentation.
__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
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
_______________________________________________
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