Xcode 4.2 Jumps to Main.M Every Time After Stopping Simulator

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

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

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

How to prevent Xcode 4 from jumping to the main.m file after every Run?

Usually this happens to me when I have a breakpoint at a position that no longer exists (code deleted i.e). GDB stops at the beginning of the program, if it finds an invalid breakpoint.

This seems to cause the switching to main.m on xcode's part.

Most often I delete all my breakpoints and start over setting the ones I really need. They tend to pile up anyway. This fixes the issue for me.

Xcode always stopping at main.m after a crash

They changed the behavior, follow this tutorial to break on all exceptions

EDIT:^{(Link might rot, so I will duplicate the info here)}

One of the hidden gems in Xcode 4.2 is the “Exception Breakpoint” feature. Once you enable it, your debugging life becomes much easier because whenever an exception is thrown in your app, Xcode will bring up the line of code that caused the exception to occur. This is particularly useful if your call stack window is empty (which I have seen happen sometimes while working on iOS apps). Instead of relying on a brief error message in the Output pane, which doesn’t contain much more than the type of exception and its error message, you get to see exactly where the problem is!

You can add an Exception Breakpoint by opening up the Breakpoint Navigator pane, and clicking on the X button in the bottom left corner:

After clicking the “Add Exception Breakpoint…” menu item, you will see this breakpoint configuration view open up:

Click the Done button and you will the new Exception Breakpoint in your list of breakpoints. If you want to have all of your Xcode workspaces include the Exception Breakpoint, right-click (Ctrl + click) on it and open the “Move Breakpoint To” menu item:

After clicking “User” in the submenu, you will see that the Exception Breakpoint is in the User group of breakpoints. Open up another project and it automatically be included in the list of breakpoints.

Happy debugging!

App always terminates in main.m

"You can add an Exception Breakpoint by opening up the Breakpoint Navigator pane, and clicking on the X button in the bottom left corner"

from this more detailed instruction

Can I prevent Xcode displaying main.m when it hits an exception?

I have setup my projects to have (at least) three tabs. One tab where I do stuff, another tab called Build Results, a third tab called Debugger. Create a tab with CMD-T, edit the tab name by double clicking where the name shows.

The Behaviours are set up for Build to switch to the Build Results tab. Running will switch to the Debugger tab. Exits unexpectedly will define what to display when an exception occurs. The settings for Running are show in the picture

This way my working tab will remain on the line where I am editing and the debugger tab can jump to where it wants to jump to.

Did you set up a sybolic breakpoint to symbol objc_exception_throw? That should stop at the line where the exception did occur, long before main.m is reached.

SIGKILL signal everytime I stop debugging

Well, thats's somehow expected because a SIGKILL signal is really sent everyime you stop or relaunch the debugger.

You can try the band-aid solution explained here. In short:

1. Open preferences and then Behaviors;
2. Select "Run completes";
3. Mark "Show tab" and fill the input with "Edit"
4. Do the same with "Run exits unexpectedly"

About the random sigkills, maybe you should track references counting with Instruments. There's a section about it on the memory management guide if you will.

XCode debugger stops with SIGKILL on Stop button

SIGKILL is what you are sending to the process when you stop the debugger. There isn't anything wrong, but sometimes it does show up and switch you to the main.m file which is useless and annoying.

To get around it, don't bother stopping the executable from Xcode. Just leave it running, and when you want to run again, just re-launch with the "Play" button and the previous task will be terminated anyway.

Thread not stopping on actual line of code when crash in XCODE 4.2

If you look at the stack trace, you'll see handle_uncaught_exception. This means that your app is crashing because an exception was thrown and not handled. Often, this means you tried to use a deallocated object, or you tried to access something beyond the end of an array.

Of course, at this point, it's hard to tell what went wrong. Luckily, Xcode will let you set a breakpoint to stop whenever an exception is raised, which will give you far more context.

It's really easy; just choose "Add exception breakpoint" here:

Then run your app again and you'll stop right where the error was found.

---

Related Topics