Cocoa mail archive
Re: Breaking into debugger after program hangs....
FROM : John Draper
DATE : Fri Apr 29 22:41:30 2005
j o a r wrote:
>
> On 29 apr 2005, at 04.42, John Draper wrote:
>
>> One can be casted to another? Even though one is an object, and
>> another is a procedure call?
>
>
> You shouldn't compare an object (the data) to a "procedure call" (the
> code working on the data). Apples and oranges...
Yea _ I know that... but the way they can make a NSArray look like a
CFArray by making
identical structures was news to me.
>
>>> 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".
>
>
> I think you should try to familiarize yourself with the toolbar
> buttons. Try to map them to the GDB command line equivalents.
I would really like to know how to do this... Unfortunately, by
pressing the buttons, I get no
equivelant "commands" being entered into the Console Command line.
Does there exist a document
that can map these command line equivalents?
>>> 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?
>
>
> Outside of the debugger, meaning running with no GDB attached to your
> application. Just like if you had been double-clicking it in the
> Finder. I wasn't sure if you were running in the Xcode debugger or
> not from some of your descriptions - but it seems from your latest
> descriptions that you are.
Yes - that is right.... I never considered others would not even use it
at all, but because I'm such
a lame programmer, I need as much "crutches" and support as I can find.
>
> On 29 apr 2005, at 04.48, John Draper wrote:
>
>> I don't have a stack crawl list - I have two sections in MY window.
>> Bottom one is for the source
>> code being debugged, and the top shows the variable values in the
>> context of where my program
>> hit a breakpoint. NO stack crawl window... I see it in
>> documentation screenshots, and I'm sure
>> there is a way to get it to display it, but I just haven't found it
>> yet.
>
>
> Have a look at this screenshot:
>
> <http://developer.apple.com/documentation/DeveloperTools/Conceptual/
> XcodeQuickTour/art/xc_debugwindow.gif>
Yea - I see this screenshot - I can get one also in the X-Code help
section, but it sure took me
a while to find out how to get it to display. Is is also possible to
get a display of the contents in
Allocated memory like Obj C Object references, and identify what they
are? getting that
info in an extra window, and allowing me to copy and past this data
would be a godsend if I
ever figure out how to get this list.
>
> Top left: Per-thread backtrace
> Top right: Local variables
> Bottom: Source
>
> Are you missing the backtrace pane? See the little split divider
> resize control in the middle of the three panes, the one with the
> single dot? If you do, can you move it? If you don't, try to use the
> green window title bar button to maximize your window - does the
> third pane show up?
Describing these icons in words is very hard for me to follow. But I'm
sure you don't want to
snap a screen shot and annotate it either. But if you do, let me know
first so I can privately
tell you where to sent it. Since I eventually found out how to get
it, my other more pressing
task is for me to examine allocated objects (and hopefully identify
de-allocated ones), would
most certainly lead me to my goals and find a solution.
> I remember having problems with Xcode 1.5 when i first installed it -
> parts of my Xcode windows could end up outside of the visible frame
> of the window. Maximizing usually would bring things back in order,
> but I also suggest that you try Nick's suggestion with moving aside
> your ".mode1" (really weird name btw...) file. You could also try the
> "Switch Debugger Layout" menu item at the bottom of the Debug menu -
> it might fix the window layout if it's borked.
That's what I eventually did.... but the first time I tried it, it
didn't do anything, but I would up doing it 3 times to converge on a
screen layout I needed.
John
DATE : Fri Apr 29 22:41:30 2005
j o a r wrote:
>
> On 29 apr 2005, at 04.42, John Draper wrote:
>
>> One can be casted to another? Even though one is an object, and
>> another is a procedure call?
>
>
> You shouldn't compare an object (the data) to a "procedure call" (the
> code working on the data). Apples and oranges...
Yea _ I know that... but the way they can make a NSArray look like a
CFArray by making
identical structures was news to me.
>
>>> 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".
>
>
> I think you should try to familiarize yourself with the toolbar
> buttons. Try to map them to the GDB command line equivalents.
I would really like to know how to do this... Unfortunately, by
pressing the buttons, I get no
equivelant "commands" being entered into the Console Command line.
Does there exist a document
that can map these command line equivalents?
>>> 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?
>
>
> Outside of the debugger, meaning running with no GDB attached to your
> application. Just like if you had been double-clicking it in the
> Finder. I wasn't sure if you were running in the Xcode debugger or
> not from some of your descriptions - but it seems from your latest
> descriptions that you are.
Yes - that is right.... I never considered others would not even use it
at all, but because I'm such
a lame programmer, I need as much "crutches" and support as I can find.
>
> On 29 apr 2005, at 04.48, John Draper wrote:
>
>> I don't have a stack crawl list - I have two sections in MY window.
>> Bottom one is for the source
>> code being debugged, and the top shows the variable values in the
>> context of where my program
>> hit a breakpoint. NO stack crawl window... I see it in
>> documentation screenshots, and I'm sure
>> there is a way to get it to display it, but I just haven't found it
>> yet.
>
>
> Have a look at this screenshot:
>
> <http://developer.apple.com/documentation/DeveloperTools/Conceptual/
> XcodeQuickTour/art/xc_debugwindow.gif>
Yea - I see this screenshot - I can get one also in the X-Code help
section, but it sure took me
a while to find out how to get it to display. Is is also possible to
get a display of the contents in
Allocated memory like Obj C Object references, and identify what they
are? getting that
info in an extra window, and allowing me to copy and past this data
would be a godsend if I
ever figure out how to get this list.
>
> Top left: Per-thread backtrace
> Top right: Local variables
> Bottom: Source
>
> Are you missing the backtrace pane? See the little split divider
> resize control in the middle of the three panes, the one with the
> single dot? If you do, can you move it? If you don't, try to use the
> green window title bar button to maximize your window - does the
> third pane show up?
Describing these icons in words is very hard for me to follow. But I'm
sure you don't want to
snap a screen shot and annotate it either. But if you do, let me know
first so I can privately
tell you where to sent it. Since I eventually found out how to get
it, my other more pressing
task is for me to examine allocated objects (and hopefully identify
de-allocated ones), would
most certainly lead me to my goals and find a solution.
> I remember having problems with Xcode 1.5 when i first installed it -
> parts of my Xcode windows could end up outside of the visible frame
> of the window. Maximizing usually would bring things back in order,
> but I also suggest that you try Nick's suggestion with moving aside
> your ".mode1" (really weird name btw...) file. You could also try the
> "Switch Debugger Layout" menu item at the bottom of the Debug menu -
> it might fix the window layout if it's borked.
That's what I eventually did.... but the first time I tried it, it
didn't do anything, but I would up doing it 3 times to converge on a
screen layout I needed.
John
