Xcode 4.2 每次停止模拟器后都会跳转到 main.m

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

提问by pixelfreak

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.

这更像是一个普遍的烦恼。每次停止模拟器后，Xcode 都会因为某种原因跳转到 main.m。在左侧导航中，它跳转到调试导航器。

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.

这个问题并不新鲜，但似乎变得更糟。在写这篇文章的时候，我在 GM 种子上，但是这个问题在 XCode 4.2 final 中仍然存在。这在以前版本的 XCode 中不是问题。

采纳答案by Krishnabhadra

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.

当我们从 xcode 开始调试时，调试器将自己设置为监视来自操作系统的信号。当我们按下 XCode 中的停止按钮（或点击 cmd + R - 它首先停止现有实例运行，然后尝试启动新实例，有点等同于我们先手动按下停止然后运行）SIGKILL 被发送到调试器。

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.

每当中断原因来自应用程序外部时（换句话说，所有发送 SIGKILL 的情况，例如按下停止按钮），调试器都会跳转到main，因为main 是应用程序的根目录，也是您的应用程序与 OS 相遇的地方。调试器无法确定发出此 SIGKILL 的原因（按 xcode 中的停止按钮/按 cmd + R/ 从多任务栏中删除应用程序等），但它将 SIGKILL 视为外部中断，与您的代码无关。所以它跳转到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.

如果中断的原因是来自应用程序内部（如应用程序崩溃/SIGABRT），调试器会处理它并跳转到我们通常看到的崩溃位置。

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

我不认为这是 xcode 错误，而是处理 SIGKILL 的正常方式。但是如果你想留在你的代码并且不想跳转到 main 你可以做两件事

1. 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)

2. 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 thisand this. But I don't have much hope of a positive action from Apple

1. 你可以按照 Gabe 的建议去做。正如BBonified所说，它就像一个创可贴，但我认为它应该起作用（我个人从未尝试过）

2. 在此处报告功能的错误/请求。让我告诉你，你不是第一个这样做的人。已经报告了一个错误。看到 这个和这个。但我对苹果采取积极行动的希望不大

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.

我同意你的看法，这有时很烦人。特别是如果您在以前的 XCode 版本中经历过不同的经历。但我们只能接受他们在这里给予的东西。

回答by Krishnabhadra

I guess it's fair to call it a bug, Xcode 3 specifically suppressed this useless artefact.

我想将其称为错误是公平的，Xcode 3 专门抑制了这种无用的人工制品。

I've had success (four times and counting) with this one-liner in ~/.gdbinit:

我在以下方面取得了成功（四次和计数）~/.gdbinit：

handle SIGKILL nostop noprint nopass

Taken from this gdb manual:

取自本 gdb 手册：

http://www.delorie.com/gnu/docs/gdb/gdb_39.html

http://www.delorie.com/gnu/docs/gdb/gdb_39.html

Not sure if it applies to lldb as well.

不确定它是否也适用于 lldb。

回答by avance

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

我尝试了大卫的建议，但这对我不起作用，所以我尝试了类似的方法：

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

1. 打开首选项，选择行为选项卡。
2. 从左栏中选择“运行意外退出”。
3. 选择“使用当前视图显示调试器”。

I'm using Xcode version 4.2 build 4D199.

我使用的是 Xcode 4.2 版本 4D199。

EDIT: That worked for about 15 minutes. Then it reverted to bringing up main.m in the editor again.

编辑：这工作了大约 15 分钟。然后它又恢复到在编辑器中打开 main.m 。

回答by David

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:

一切都可以通过 Xcode 用户首选项中的设置解决：

• 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.

你去吧。从现在开始，Xcode 不会移动您的编辑视图。享受。

PS: Xcode version 4.2 Build 4C199

PS：Xcode 4.2 版本 4C199

回答by Gabriel

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.

转到首选项 -> 行为。在左侧选择“运行完成”。选中“显示选项卡”旁边的框并输入选项卡名称。我使用“编辑”。这样，无论何时停止，您都将始终返回到名为“编辑”的选项卡。

回答by David

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)

（每一步后等待 0.1 秒）

command-period

命令周期

command-1

命令 1

down arrow

向下箭头

up arrow

向上箭头

command-j

命令-j

enter

进入

Use this key instead of the normal stop, and you end up with your cursor positioned where you left it. Very nice.

使用此键而不是正常的停止键，您最终会将光标定位在您离开它的位置。非常好。

回答by Jeffrey Berthiaume

Xcode -> Preferences

Xcode -> 首选项

Under Behaviors

在行为下

Click on Run Starts

点击运行开始

Checkbox for [Show] debugger with [Current Views]

带有 [当前视图] 的 [显示] 调试器的复选框

...worked for me.

...对我来说有效。

回答by Lazarus

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

我已经能够跟踪违规事件的顺序。当您运行应用程序并使用多个线程时，将出现 SIGKILL 错误消息。例如，在我的应用程序中使用 UIWebView 时，它将中止到 main.m。我验证了当未调用 UIWebView 时，可以停止 XCode，而不会出现 SIGKILL 错误消息将用户返回到 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.

看起来至少有两个线程在初始化 UIWebView 时启动。但是，您在应用程序运行期间创建的任何线程都会导致 SIGKILL 不正确地通知 XCODE 返回主线程。

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

您可以在 GDB 中看到在 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

【切换到进程24957线程0x2103】

【切换到进程24957线程0x7403】

【切换到进程24957线程0x207】

程序以退出代码结束：0

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

这绝对仍然是 XCODE 的一个错误，希望能得到修复。

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.

目前，如果您避免执行启动单独线程的代码，它不会将视图更改回 main.m 对于启动其他线程的代码，我建议退出模拟器以返回到 XCODE 中的编辑模式。

回答by pixelfreak

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.

这可能不多。通过在停止应用程序后等待 2 秒左右，然后重新启动它，我能够在 99% 的时间内避免这个问题。

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

更新：升级到最新的 Xcode 后，系统提示我使用 LLDB 而不是 GDB。现在这个问题似乎不存在了。

回答by delany

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。