When we start debug from xcode, the debugger sets itself up to monitor signals from OS. When we press stop button in XCode (or hit cmd + R - which first stops existing instance running and then try to start new one, somewhat equalant to we press manually stop first and then run) SIGKILL is sent to the debugger.
Whenever the cause of interruption is from outside the app (in other words all cases where SIGKILL is sent, like stop button press) , debugger jumps to main
, since main is the root of the app and the place where your app meets the OS. Debugger has no way to identify why this SIGKILL is issued (pressing stop button in xcode/ press cmd + R/ delete app from multitasking bar etc), but it treats SIGKILL as outside interrupt, and nothing related with your code. So it jumps to main.
If the cause of interruption is from inside the app (like app crash/SIGABRT) debugger handles it and jumps to the place of crash, which we normally see.
I do not consider this as an xcode bug, rather a normal way of handling SIGKILL. But if you want to stay at your code and do not want to jump to main you can do two things
You can do as Gabe suggested. As BBonified said, it is like a band-aide, but I think it should work (personally I never tried that)
Report a bug/request for a feature here. Let me tell you you are not the first one to do so. Already a bug has been reported. See this and this. But I don't have much hope of a positive action from Apple
And I agree with you, it is sometimes annoying. Especially if you have experienced differently in previous XCode versions. But we can only take what they give here.
I guess it's fair to call it a bug, Xcode 3 specifically suppressed this useless artefact.
I've had success (four times and counting) with this one-liner in ~/.gdbinit
:
handle SIGKILL nostop noprint nopass
Taken from this gdb manual:
http://www.delorie.com/gnu/docs/gdb/gdb_39.html
Not sure if it applies to lldb as well.
I tried what David suggested but that didn't work for me, so I tried something similar:
I'm using Xcode version 4.2 build 4D199.
EDIT: That worked for about 15 minutes. Then it reverted to bringing up main.m in the editor again.
I had the same problem and it WAS really annoying, especially when you were in the middle of debugging, stopping/launching the app several times in a row after small modifications.
Everything is solvable through settings in Xcode user preferences:
There you go. Xcode will not move your editing view from now on. Enjoy.
PS: Xcode version 4.2 Build 4C199
Go to Preferences -> Behaviors. Choose "Run Completes" in the left hand side. Check the box next to "Show Tab" and enter a tab name. I use "Edit". This way whenever you stop, you will always be back at a tab called Edit.
None of the other solutions listed were suitable for me, so I made a macro (using an external hotkey utility).
(wait 0.1 second after each step)
command-period
command-1
down arrow
up arrow
command-j
enter
Use this key instead of the normal stop, and you end up with your cursor positioned where you left it. Very nice.
Xcode -> Preferences
Under Behaviors
Click on Run Starts
Checkbox for [Show] debugger with [Current Views]
...worked for me.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With