Xcode 4.2 jumps to main.m every time after stopping simulator

Question

This is more of a general annoyance. Every time after stopping the simulator, Xcode jumps to main.m for some reason. On the left nav, it jumps to the Debug Navigator.

Is there a way to fix this?

It's annoying because I might be testing a certain line of code, and now each time, I need to make a couple of clicks just to go back to that code.

This problem is not new, seems to get worse though. At the time of writing this, I was on the GM seed, but this problem persists in XCode 4.2 final. This was not a problem in previous versions of XCode.

Well, obviously I'd like to know if there is a way to fix this :) — pixelfreak, Oct 07 '11 at 04:36
How are you stopping the simulator - by quitting it, or by hitting the 'Stop' button in XCode? — lxt, Oct 07 '11 at 10:20
@lxt By using the shortcut 'Cmd-.' which is equivalent to hitting the 'Stop' button — pixelfreak, Oct 07 '11 at 18:50
Why is this question closed? It was valid and I have the same problem. — dontWatchMyProfile, Oct 16 '11 at 23:44
Ah, there is a "reopen" link under the keyword tags. @dontWatchMyProfile, do you see it? — pixelfreak, Oct 20 '11 at 04:12
It's a common problem. It looks like it crashes somewhere by the time you hit stop and shows an error in the return line. Would love to have a solve for that. — yinkou, Nov 02 '11 at 21:52
Dear original poster, please consider trying user401925's answer again and maybe marking it as correct; I've fixed a small typo he made (the command is called ‘handle’ rather than ‘signal’). — Andrey Tarantsov, Feb 07 '12 at 18:28

Krishnabhadra · Accepted Answer · 2013-02-20T11:16:27.653

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.

score 11 · Answer 2 · edited Feb 07 '12 at 18:27

11

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.

edited Feb 07 '12 at 18:27

Andrey Tarantsov

8,965
7
54
58

answered Nov 09 '11 at 16:01

It still stopped on SIGKILL once, but that seemed to be the rare exception after a lot of runs with and without this flag. Also, I was worried that `nopass`ing `SIGKILL` would leave the app running. According to Activity Monitor, it doesn't - the app correctly disappears. – Nov 09 '11 at 16:11
Like my own attempt this worked for about 15 minutes. I am guessing something else is overriding this setting elsewhere (the file contents are intact). – avance Nov 18 '11 at 23:09
It has kept working for me. If it stops, I will try to track down why. – Nov 19 '11 at 21:04
This doesn't seem to work for me in Xcode 4.2.1 in Lion with GDB. – Zev Eisenberg Jan 25 '12 at 17:19
3

Guys, this DOES work, but the command is called ‘handle’, not ‘signal’. Putting ‘handle SIGKILL nostop noprint nopass’ into ~/.gdbinit has fixed the problem for me. – Andrey Tarantsov Feb 07 '12 at 18:20
This worked for me, but I had to restart XCode before it started working. Also, just want to note that the .gdbinit file goes in your user / home directory. I know the ~ denotes that, but I just want to make that crystal clear. – Sam Feb 10 '12 at 17:31

avance · Answer 3 · 2011-11-18T21:34:41.187

7

I tried what David suggested but that didn't work for me, so I tried something similar:

Open Preferences, select Behaviors tab.
Select "Run exits unexpectedly" from left column.
Select "Show debugger with current views".

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.

edited Nov 18 '11 at 21:34

answered Nov 18 '11 at 20:36

avance

1,993
2
21
23

I had this problem while I was first running my app (not while stopping the simulator). This seem to be the correct solution. – Eric Brotto Dec 02 '11 at 10:44
2

Actually, you need to follow David's answer too. You need to select "Show" and the value to "Current" – Eric Brotto Dec 02 '11 at 11:43

score 6 · Answer 4 · edited Nov 16 '11 at 16:15

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:

Just go to "run completes"
There find the "Show" line and click the checkbox
On the same line modify target to go to "Current" in the dropdown menu.

There you go. Xcode will not move your editing view from now on. Enjoy.

PS: Xcode version 4.2 Build 4C199

score 1 · Answer 5 · answered Nov 02 '11 at 21:48

1

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.

answered Nov 02 '11 at 21:48

Gabriel

3,039
6
34
44

1

This is only a band-aide for the problem. The issue is that XCode is erroring and jumping to main.m for no reason. Adjusting the editor settings like you describe only adjusts XCode's behavior in that situation (as well as all other run completions). – BBonifield Nov 02 '11 at 22:52

score 1 · Answer 6 · answered Dec 30 '11 at 22:03

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.

score 1 · Answer 7 · answered Jan 19 '12 at 07:49

1

Xcode -> Preferences

Under Behaviors

Click on Run Starts

Checkbox for [Show] debugger with [Current Views]

...worked for me.

answered Jan 19 '12 at 07:49

Jeffrey Berthiaume

4,054
3
35
45

score 1 · Answer 8 · edited Jun 20 '20 at 09:12

None of the preference adjustments seem to work for me.

I have been able to track the offending sequence of events. The SIGKILL error message will occur when you run your app and use multiple threads. For instance, when using UIWebView in my app it will abort to main.m. I verified that when UIWebView is not called, XCode can be stopped without the SIGKILL error message returning the user to main.m

It looks like there are at least two threads that get started when initializing a UIWebView. However, any threads created by you during the running of your app will cause the SIGKILL to improperly notify XCODE to return to the main.

You can see this in the GDB that there is a switch just before SIGKILL:

[Switching to process 24957 thread 0x2103]

[Switching to process 24957 thread 0x7403]

[Switching to process 24957 thread 0x207]

Program ended with exit code: 0

It is definitely still a bug with XCODE that will hopefully be fixed.

For now, if you avoid executing code that launches a separate thread, it will not change the view back to main.m For code that does launch additional threads, I would recommend quitting the simulator to return to edit mode in XCODE.

score 0 · Answer 9 · answered Mar 15 '13 at 20:26

I was trying to find the offending line when my code was breaking, so what I did was:

Go to where you define your breakpoints (breakpoint navigator, according to the documentation)
Click in the "+" sign in the left bottom corner of the navigation area
Click on Add Exception breakpoint
You click Done
Run your app

Xcode shows you the offending line.

pixelfreak · Answer 10 · 2012-03-15T22:43:04.850

0

This might not be much. I was able to avoid this problem 99% of the time by waiting for 2 seconds or so after stopping the app, before relaunching it.

UPDATE: After upgrading to the latest Xcode, I am prompted to use LLDB instead of GDB. The problem seems to be gone now.

edited Mar 15 '12 at 22:43

answered Feb 05 '12 at 23:13

pixelfreak

17,714
12
90
109

score 0 · Answer 11 · answered Mar 14 '12 at 17:16

None of these solutions worked for me and I find the behavior too intrusive to put up with.

I get round it by using the 'Assistant Editor' instead of the editor as my main editing window. You access the Assistant Editor using the tiny little bow tie button at the top right of the single window.

You can set then it to 'Manual'. Click on the button that is the far left crumb of the breadcrumb trail at the top of the Assistant Editor frame and select Manual from the pop-up menu that appears. The Manual setting allows you to select the file you're editing by clicking on the second to last crumb of the breadcrumb trail and selecting the file from the pop-up that appears.

I then just minimize the size of the main editor - or use it as a secondary editing window, useful given that you can't split the editors into multiple frames any more. Far from ideal - but that's XCode 4 for you.

Xcode 4.2 jumps to main.m every time after stopping simulator

11 Answers11

Linked

Related