Re: Breaking into debugger after program hangs....
Re: Breaking into debugger after program hangs....
- Subject: Re: Breaking into debugger after program hangs....
- From: John Draper <email@hidden>
- Date: Thu, 28 Apr 2005 19:42:36 -0700
j o a r wrote:
On 28 apr 2005, at 22.43, John Draper wrote:
I never DID understand this "Toll free" concept.... can someone
come forward and explain
this? Isn't this just a kind of "wrapper" around the lower level
Carbon Procedural calls?
It means that at the data level, the two are one and the same (for
example CFArray == NSArray), and that any operation that can work on
one, can also work on the other (possibly requiring a "cast" to help
identify the type).
One can be casted to another? Even though one is an object, and another
is a procedure call?
So you are saying the NSArray Method maps to a procedure that uses a
CFArray?
Well - then perhaps I was wrong in how I enabled Zombies, because I
just followed the
instructions in the Tech Note.... It clearly says I just select
the Target (Executeable)
and go to File --> Show Inspector --> Arguments (tab) --> and put in
the "NSZombieEnabled = YES"
Is that right? If so, then my program is NOT reporting what
happened.... Do I need to
issue some "secret" command to "gdb" to get this info?
That should be right, barring the special case that Nick mentioned.
Yes - I see...
I'm a bit concerned that you say that you enter "NSZombieEnabled =
YES", because I think that at least in Xcode 1.5 and later, you enter
NSZombieEnabled in one field, and YES in another. But you probably
did the right thing - it's difficult not to.
You are right - there ARE two seperate fields, I just didn't mention
that, sorry.
And as of yet - nobody came forward to tell me how I can "break" out
of a "Hang" and
get back into the debugger.... isn't there ANYONE out on this list
that knows?
And where are these APPLE PEOPLE I heard about who actually read
this list... Can't any of you please answer this?
I would suggest that you drop that tone of voice immediately if you
want to find help on this or any other mailing list. I don't see how
shouting would make anyone more inclined to help you...
I wasn't shouting.... it is impossible to determine a persons state of
mind on these forums,
and apologies if I made that impression.
If your application is signaled, like you say happens in your case,
you should break into the debugger automatically.
I would think so....
If you want to break automatically on exceptions, break on
"-[NSException raise]", using the instructions I gave you earlier
(although I don't think it would help you right now).
Ok, I will try that - I just added it to my ever growing "try list".
If you want to break manually, hit the "pause" button in the debugger
window toolbar.
Oh - I see... I never would have associated the "pause" with "breaking
into the debugger".
Are you sure you're using the debugger at all?
Yes.... I set and get to breakpoints - bring up console window to type
in "gdb" commands of
which I'm still learning, little at a time.
You hit Cmd+R to launch the application outside of the debugger
What do you mean "Outside the debugger", are you referring being within
X-Code?
and Cmd+Y to launch it in the debugger.
Yes - or I often find it quicker to type "r" to the "gdb" prompt to
restart the application.
Does that mean the application is already loaded into the "debugging"
environment? and
"r" just re-enters the code that's already in ram.
Since I'm running this in "development" style build, it takes a very
long time to load in
the program. I'm guessing it has to go out and get things and put them
together, kind of
like a linker... things like loading in the Frameworks, Libraries,
and tie them all together.
The Link phase is very quick, so "some" linking takes place.
If I were to re-start the application by going to "Build --> Build and
debug" path, it
takes a really long time to start up. But from "gdb", just an "r"
starts it up
right away..
John
_______________________________________________
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