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.
Related
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.
In Xcode, is there a way to prevent my assistant editor's file from hopping back into the main editor whenever a breakpoint there is hit?
I usually have a test in one editor and my source in the other; it's not ideal to have them rearranging like that during debugging.
I've tried all sorts of combinations in Behaviors, but have never quite landed on a solution.
Turns out there is! Open up Preferences…, click the Navigation tab, and select "Uses Focused Editor."
This will leave the breakpointed file in its own editor when the breakpoint is hit, as long as that editor has focus (i.e., your cursor is in it). So, not a perfect solution, but still a good one so far.
When debugging program in Idea (I'm using 14.1.5 Community Edition), it attempts to put the line I'm currently on close to the center of the screen. And it does so every single step. However, I find this default behavior very annoying, it looks like the code is jumping around.
I wonder if there a way to customize the debugger view in a way that the code would be fixed (as long as I'm not leaving one screen of code) and the current line highlighting would be moving around? (I didn't find it in the Debugger section of the settings.)
Many thanks.
You want to disable "Focus application on breakpoint" which is in the settings under Build,Execution, Deployment > Debugger - it's the first checkbox. It's help documentation reads:
If this check box is selected, on hitting a breakpoint, IntelliJ IDEA will show the location of this breakpoint in the editor and will attempt to bring its frame to the front.
This should do the trick.
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 Xcode 4 (4.2), is there a way to keep the Project Navigator view open and Debug Navigator view open as well. Must a user have one or the other, but not both? And the other navigators?
Apple seems to have decided that if you want to see the debug view, you don't want to see the files in your project. WTH? Am I getting this wrong? Did Apple Xcode UI guys even talk to developers before designing the UI for Xcode 4?
Sigh...
You can indeed have more navigators open at once, if you are prepared to have multiple windows open. I know it's not exactly what you're asking for, but for multiple display setups it's very handy. Xcode provides "behaviors" to help automate this process if you only want certain things showing at certain times.
For example, a common pattern that developers follow is to setup a behavior for "Run starts" that opens up a new window setup for debugging. Start by creating a new tab in your main Xcode window by pressing command-T, and double-click on the tab's title to rename is "Debug", or whatever you like. Then drag that window out (or leave it as a tab if you like), and customise the view as required - for example, for a deb window you might have the Debug area showing at the bottom (or even covering the whole editor view), and remove the toolbar at the top by right clicking and selecting "Hide Toolbar".
Next, go to "Xcode > Behaviors > Edit Behaviors..." and choose "Run starts" in the left panel. Check the box for "Show tab" and enter the name of your newly created tab. You can also ask that tab to automatically show the Debug Navigator, and show the debugger with variables and/or console view. If you like, you can then choose "Run completes" and show the original "tab" (window), which I've setup to be called "Coding", and show the required navigator (in my case, Project Navigator).
On successfully running, Xcode will now open up your new window (or bring it to the front if it's already open) with all the settings you left it with. On stopping, your main editor will be brought back to the front.
There are loads of useful behaviors, so I would really recommend looking through them and taking the time to setup Xcode to suit your style as best as possible. All software dictates to the user how to go about doing things, and the developers can never please everybody when they decide to change the UI. The best anybody can hope to achieve is to customise the interface as best as they can to fit their style of working. If it's still an issue for you, you can either adapt to it, or, if possible, move to something else.
I'm not a fan of every new interface feature in Xcode, but I've "made it mine" with some customisations and I can still be very productive. That being said there are a lot of things that I do really like about it, and for that I can forgive it for some of the less friendly features - after all, you can't please every user.