Whenever I get a SIGABRT error in my Swift project (if it matters, in this case it was because I was programmatically creating an invalid constraint), Xcode will switch to my app delegate file and highlight the first line of the class declaration as the source of the error. But there's never any useful information there - if anything, by leaving the code I was last working on, it's more likely to take me away from where the problem is. Is there any way to change or disable this behavior?
When you crash, Xcode needs to show you something that explains the crash. I don't know of a way to get it not to show you any source at all.
Currently, Xcode will select the lowest frame in the stack of the crashing thread that has debug information, and show the associated source. It seems odd that it is highlighting the class declaration, maybe that's where an implicit init method gets charged to or something? If this always selects a not relevant place, that seems worth a bug.
But even if the source location is relevant to the crash, I still like to keep my source editor windows from getting repurposed by the debugger. I do that by setting up a Run Behavior in the Xcode Behavior Preference pane that keeps the debugger in its own tab. Just set the "Pauses" action of the Running section to Show a named tab (like "Debugger"), and to show the Debug navigator in that tab. I also do that in the "Start" action. Then when the debugger stops I get switched to that tab, and can interact with the Debugger there, leaving my source editor(s) focused on whatever I was looking at when the debugger stopped.
Related
When I run my project in Xcode a few things happen (especially if there was an exception)
The debug (output) window slides up into view
The file directory pane on the left switches to the Debug navigator
The code file you left off on switches to main.m or some other file where the error happened.
That's all great, but when I'm done running the application none of this goes back to how it was. So that means there's this constant repetition of hiding the output window, clicking on the file directory icon, and finding the file I was just on.
This is just completely unacceptable as I may run the application a dozen times in a minute.
Coming from Visual Studio, the same experience happens when debugging, but everything returns back to normal when you stop debugging.
How can I make things return back to normal?
Assuming you're using Xcode 4 or later, you can set up behaviors to set up things how you want. Under the Xcode Preferences, click on the Behaviors tab and select "Completes" under the "Running" section. You have the option to open or close any of the various panes.
Here's an interesting article on customizing Xcode to make it work better for you.
In previous versions of Xcode, when I ran into a crash (does not respond to selector, or array index out of bounds, etc) Xcode would usually open the file where the crash happened and often take me to the line where it crashed. The latest Xcode doesn't seem to be doing that which is making debugging a LOT harder.
Do I need to enable some new settings or something? I just downloaded the latest version 4.3.1 and I created a new project so the project settings should hopefully be the right defaults.
You can try this: http://blog.manbolo.com/2012/01/23/xcode-tips-1-break-on-exceptions
Summary: it can be helpful to add an exception breakpoint, which breaks when an exception is thrown, rather than when it is caught. In order to do this, go to the breakpoint navigator pane, click on the + in the bottom left corner, choose "Exception Breakpoint" from the popup menu, and accept the default settings. Note: despite being an old tip, this still works on Xcode 8 in late 2016.
This is just plain weird.
For some reason, the accelerator Cmd-Opt-L (reformat code) no longer works inside IntelliJ 10. This started with one of my projects and seems to have "spread".
Other accelerators work normally. Reformat works if I use the menu to select it, or Cmd-Shift-A and choose it from the "Find action ..." popup dialog.
I've tried to see if some conflicting application is the cause. I'm using 1Password and it defines an accelerator for Cmd-Option-L, but I disabled that, restarted IntelliJ and still no dice.
A quit-and-restart doesn't help.
More oddness. I pulled down the Code menu and typed Cmd-Opt-/ ... I can see the menu item flash and then my editor updates. If I pull down the Code menu and type Cmd-Opt-L, there's no reaction (the menu line for Reformat Code does not flash, the menu stays up). So ... one theory is that something elsewhere on my Mac is consuming the Cmd-Opt-L before it gets to IntelliJ? If that's so, how would I track it down?
Your theory is correct. As a workaround you can remap reformat code action to different shortcut in Settings | Keymap.
As for tracing the offending application, I'd try killing one by one and see when it starts working again.
I'm just starting out with Cocoa development in Xcode, doing the hello world example. I'm up to step 6 of the section "runtime debugging", which is
Using the Step Over button in the debugger toolbar, begin stepping through the code. As each line of code executes, you can examine the program’s state. The value of a variable is sometimes drawn in red to indicate that the value was modified in the last step.
Notice that the debugger pauses before executing the indicated line. After each pause, you can add additional breakpoints or choose Debug > Restart to terminate the application and start a new debugging session.
now what I've been pulling my hair out for over the last hour is the fact that this debugger will only show me assembly code. I can manually select my source code file, but as soon as I click "Step over" I'm right back in assembler view. I can't for the life of me figure out how to turn the assembler off, and make it show me my source code!
I know this article is a hundred years old, but in case anyone is wondering how to address this issue in more recent Xcode versions (as opposed to Xcode 3), you'll find the appropriate setting labeled Always Show Disassembly under Debug>Debug Workflow in Xcode 6 and up. Ensure the option is NOT checked.
In Xcode 5, the option was labeled Show Disassembly When Debugging under Debug>Debug Workflow. Ensure that "Show Disassembly When Debugging" is unchecked.
Back in Xcode 4, the Show Disassembly When Debugging setting was found under Product>Debug Workflow. Again, ensure that the option remains unchecked.
This was driving me crazy, too.
NOTE: The information above is still valid for Xcode 14+. I've applied updates to this answer as new versions of Xcode have been released. Fortunately, the option has remained unchanged since Xcode 6 (so far).
There are two other things to make sure of:
That you're looking at one of your own functions/methods. If the stack frame you're looking at is a function or method from one of the frameworks, you're going to see assembly no matter how you have Xcode configured.
That you are running a Debug build. Strip debug symbols (as in a Release build), and you'll be looking at assembly even for your own code, no matter what.
I actually figured this out before I posted, but I wanted to save others potential future headaches, (and also in case I forget later) as I could not find the answer to this by searching stack overflow, but I did find that I'm not alone.
From the run menu, select "Debugger Display" > "Source Only", or "Debugger Display" > "Source and Disassembly"
I am working on an app with an NSTextView. When I paste random bytes into it (say, from a compiled C program) it displays gibberish, as it should. However, when I -setShowsControlCharacters:YES, the same causes a crash and gives the following error multiple times:
2008-11-22 00:27:22.671 MyAppName[6119:10b] *** -[NSBigMutableString _getBlockStart:end:contentsEnd:forRange:stopAtLineSeparators:]: Range or index out of bounds
I created a new project with just an NSTextView with the same property and it does not have this problem.
My question is, how can I debug my app to find the cause of the error? I have no idea where the bug originates. I am not familiar with the debugger built in to Xcode. If anyone could point me in the right direction in terms of how to track down such a bug I would be very grateful. Thanks.
Another set of useful breakpoints to set when your debugging Cocoa apps are objc_exception_throw and -[NSException raise]. In 10.5, all exceptions travel through objc_exception_throw but if you're targetting Tiger you should set a breakpoint on both.
There are more debugging techniques at http://www.cocoadev.com/index.pl?DebuggingTechniques.
It's not really clear how much you know so I'm going to try a very basic approach, please don't be offended.
I'm assuming the NSTextView is in a external nib/xib and is not created programatically.
If so open up your nib/xib in Interface builder and click on the offending NSTextView element.
Then hit Cmd-5 or Tools->Connections Inspector
From here you can see which Outlets/Actions to look for in the actual source code.
Most likely you're problem is manipulation of a "Reference Outlet" object, or in a "Sent Action" function.
Once you have an idea of which method(s)/variable(s) you need to watch you can open up the source code for those parts in Xcode. You can then set a break point at any line by click on that line number on the left hand side of the editor window.
Click on Run->Debugger. A new window should popup, click "Run and Go" in the toolbar of that window. Your app should run as normal until it hit's the break point you set in your source code. when the break point is hit you can mouse over variables in your code in the bottom half of the debugger window. The current values of the variables should popup allowing for easy inspection.
Usually you can gain the same information by using the Top Right panel of the Debugger to inspect the variable table.
When your done with that break point click "Continue" at the top of the debugger window and your program will execute till completion or the next break point.
This should get you started with debugging under Xcode.
Their are different kinds/uses of break points and all kinds of additional fancy stuff you can do in Xcode.
For more information check out this awesome CocoaHeads video.
Good Luck,
Brian G.