Re: (no subject) (xcode gdb attach)
Re: (no subject) (xcode gdb attach)
- Subject: Re: (no subject) (xcode gdb attach)
- From: Tim Gogolin <email@hidden>
- Date: Wed, 19 Nov 2003 16:06:37 -0600
Thanks, but if I understand correctly, this requires some foresight on
my part (it has steps that must be done before running the program). If
I knew I was going to need debugging, I could have just launched my app
via the debugger...
But thanks for the unsupported, disgusting, and thoroughly entertaining
hack :-)
I'm looking forward to xcode having the ability to attach to a running
process. Bonus karma points if this behavior could be triggered
programatically (i.e. if my app, having shown an internal inspection
dialog, could *cause* xcode to attach and/or break as a result of me
pressing one of the dialog buttons)
--
Tim Gogolin
On Nov 19, 2003, at 3:50 PM, Jim Ingham wrote:
Attaching to a running process is definitely one of the things that we
intend to support, but with all the changes from PB to Xcode, we
didn't get to it yet. So no, there is no nice GUI way to do this.
The following fairly disgusting and totally unsupported hack does
work, however:
In Xcode, set a breakpoint at main, run your app, then when you stop
at main, open the gdb console, type "kill". This will kill off the
running program but leaving gdb still running. So then you can issue
the "attach <PID>" command in the console, that will attach gdb to the
real version of your app. Now you need to convince Xcode that the
target process is actually there. I usually do this by typing "stepi"
in the gdb console. The point is that when the target stops gdb will
send a message to Xcode telling it this, and then Xcode will nicely
sync up with the target, get the backtrace, etc. stepi is the
smallest forward you can move the app (step one instruction), so it is
the safest way to get it to move a bit and then stop.
Hope this helps,
Jim
On Nov 19, 2003, at 12:44 PM, Tim Gogolin wrote:
My situation:
I have an app (built in xcode) that can detect an internal error
situation and post a modal dialog that helps me understand part of
the problem. The dialog is posted via [myApp runModalForWindow: w],
so the stack is still intact. If I switch to the terminal, run gdb,
and "attach" to the process I can get a good back trace.
Presumably I could continue to debug from the command line (ouch,
command line debugging). The project is open in xcode and I launched
the app from xcode (but not by using the "debug" command). Is there
any way to "change my mind" and get the debugging UI up and running,
in the same way that command line gdb will allow one to start
debugging after the app has already been running normally?
--
Tim Gogolin
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
--
Jim Ingham email@hidden
Developer Tools
Apple Computer
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.