I don't know what has changed on my setup, but it used to be that when my (Swift) code crashed, the debugger would show the offending line of source code.
Now no matter what the problem is, the debugger only highlights the line in AppDelegate.swift where UIApplicationMain is defined.
I can tell by putting in print statements more or less where in the code the problem arose, however... what's the point of having a debugger if it never conveys any information and I just have to do everything "old school" with print statements -- especially if there are asynchronous processes going on in which the print statement isn't necessary a reliable indicator of where the crash occured?
I've seen threads from years ago that talk about going into "Preferences -> Behaviors" and modifying what gets shown when the code exits unexpectedly. But (a) I never needed this in the past, and more importantly (b) this seems to have no effect, i.e. the debugger is still just quitting on main.
Is there a good way to get the old, specific, debugging behavior back?
I'm currently running Xcode 7.0, but this behavior occurs with 7-GM Seed, and even now when I go back to try 7 beta 5 and beta 6, which used to work.
Go to the Debug Navigator (cmd-7), click the plus button in the bottom and select Add Exception Breakpoint. This will break at the actual line where the problem happened.
In the exception breakpoints detail editor create debugger command action and in the text box enter po $arg1. This will show the error message in the debug console.
The previous answer was on the right track, but this answer is more relevant today:
On Xcode 9.2 with Swift 4, do this:
Use Command-8 to bring up the Debug Navigator.
Click the + in the lower left
Select Swift Error Breakpoint
That's it! :)
Related
It's been bothering me since Xcode 6, that whenever I set 'All Exceptions' without any other breakpoints, Xcode would stop at start when I init a UILabel view wrapper in RootVC.
If I try to remove the causing line, another "random" line would trigger it again. Thoughts on what caused the exception?
This breakpoint comes from an exception that was thrown by TFileDescriptorContext. All Exceptions halts also on C++ exceptions.
It gives you a good indication where the problem comes from. Take a look if all fonts that are listed in Info.plist are part of your application bundle.
"Normally" you are not interested in C++ exceptions when you are in Objective-C, so feel free to ignore them.
Edit: This problem has been discussed several times here on SO. Updating when I can find the posts again which might give you even a deeper insight.
Where XCode generate error for application crash ?
I'm crazyng ! My application when open second file xib with webview then it crash. But I don't know why ? how can i Know where is error ?
You need to learn how to use the debugger in Xcode.
Run your app under the debugger then instead if simply getting a stack trace Xcode will stop at the line the fault occurs and show you your code and variables. You can then examine the contents of your variables, the call tree, etc. and hunt down the problem.
Once you know the general area of the problem you can place breakpoints to pause your application before the problem occurs and check whether your variables have the values expected etc. Then you can run till the next breakpoint, or step through your code a line at a time.
You can add code, such as NSAssert's and NSLog's to your app to check progress and display information without stopping the run, etc.
It's a process, and some problems will be harder to track down, but you'll get quicker at it with practice.
The Xcode documentation will tell you all about the debugger.
HTH
So there I am, working on a Silverlight app, and between one build & run and the next, my debug output goes away. Where before I had dozens of lines of Debug.Writeline text, I now have only the module load and thread messages.
Yes, I'm in debug mode (vs. release mode).
Yes, my Output window says "Show output from: Debug".
Yes, when I right-click on the output window, every option is checked.
No, my Tools > options > debugging > general > "Redirect all output text to the immediate window" is not checked.
All I can figure (and it's a wild guess) is that for some reason, the VS debugger isn't attaching to the Silverlight app like it should.
What's weird is this has been happening for the last couple of days, out of the blue. And just as suddenly, all my debug messages start showing up again.
This is VERY frustrating.
EDIT: Of course, after returning to the project after the weekend, all Debug messages are back. No idea what was causing the issue, so I'm sure it will happen again.
Now the question is: should I leave this question open in case the problem arises again in the near future? What happens to an unawarded bounty?
I found the same problem and just by setting options → debugging → output window → Thread Exit Messages to true the output windows was begin to send the right messages !?
I had exactly the same issue. Out of the blue, debug.print stopped working. In my case, it used to go to the Immediate Window. Nothing there. Nothing in the Output window. I followed several suggestions to no avail until I found this one at http://www.experts-exchange.com/questions/26894732/Debug-Print-and-Debug-Write-no-longer-work-in-Visual-Studio-2010.html
There is a context menu in the Output/Debug pane. The "Program Output"
menu item was accidentally cleared.
Checked the item and it started working again (even though my output was the immediate window). What a relief...
Ensure that the DEBUG conditional compilation symbol is defined. The Debug class suggests that you "add the /d:DEBUG option to the compiler command line when you compile your code using a command line, or add #define DEBUG to the top of your file".
Did you create or modify an Application config? If yes: the initial created configuration by VS does contains the necessary wiring configurations to enable the debugging at all. Not sure what and if there are counterparts in Silverlight, but in WPF environments simply replacing the app.config will have the same effect as you expierience.
Check the Immediate Window. Check the options. There is a general setting that says "send Debug output to Immediate Window"
The only error I ever get is SIGABRT in main. This is getting incredibly frustrating as I have to guess what line caused the error and why.
This is a far cry from visual studio's informative error messages. It's basically like sending off an entire novel to an editor and the only notes you get back are: "There is a problem somewhere in your book. There may be many or just one and they are either gramatical or to do with spelling."
I just don't know how anyone can work like this. What am I doing wrong? Surely I'm missing something essential.
Write some NSLog() into your code and you'll see it in the console. It's a great help to narrow down a crash.
if you have encountered memory problems (aka – your app crashes for no apparent reason because you attempted to use an object that you deallocated to soon) setting NSZombieEnabled = YES can help you diagnose the problem.
Normally, when your app crashes in this way and you look at the log it tells you nothing (thanks Apple!). However, if you select your executable (under Executables in Xcode), hit the info button (round blue thing at the top), select arguments and put this in the bottom screen NSZombieEnabled = YES the log will give you more information.
Now, if your app crashes the log will have an indication of the object you attempted to access that has already been deallocated. Not forget to turn it off before you deploy it – you don’t want a bunch of nszombies running around your clients phones…
http://howtomakeiphoneapps.com/nszombie-and-xcode-oh-my/27/
Im using XCode 4 and seeing a problem with debugging that did not exist in 3.x.
I am putting a breakpoint at a line where I call an object method.
Product *p = [[Product alloc] init];
[p print]; <-- Put a breakpoint here
After control stops at that line, I try to step into the method (F7). But nothing happens. System just skips over the line and goes to the next line (same behavior as Step Over).
Step into works fine for plain C language projects. The problem is with Objective-C methods. How do I fix this problem? Thanks.
Not sure if this will help -- Go into system preferences, and under the Keyboard general settings ensure that the "Use all F1 F2 etc. as standard function keys" option is checked.
F7 started to work for me after I checked that.
Hope that helps...
Check that the instance is not nil before trying to step into it's instance method. As embarrassing as it may seem, we all do it occasionally.
Stepping into ObjC method calls is not always possible. The way it was explained to me, there are internal runtime data structures that must be in a consistent state in order to reliably step into an ObjC method. If those internals happen to be in an inconsistent state when the program stops at your breakpoint, stepping in in the debugger will fail, and it will step over the call instead. This was also true in Xcode 3, and really has little or nothing to do with Xcode, but is an ObjC runtime and debugger issue. I estimate anecdotally (working in Xcode full-time for 3+ years) that stepping into an ObjC method call fails ~5% of the time. I find that it happens most often when it will be the most inconvenient to me. :)
That said, if you're NEVER able to step into ANY ObjC method call, then there's likely another problem, as I've been able to step into ObjC method calls many times with Xcode 4, and don't see this problem any more or less often than I did with Xcode 3.
fn+f7 always works for me. Although step into in Obj-C is kinda weird from time to time. You'd better set more breakpoints if you know where the code is heading.
I don't know enough about OSX to understand why this is fubar but I just tried changing the default key bindings to f13-f17 for all the usual bindings of pause/continue, step into/out of etc. Works for me. Pretty sucky QA on the XCode4 team possibly?
Switching to the gdb debugger works for me. Go to Edit Schemes, the Info tab for the Run phase, change from LLDB to GDB.
It's still not perfect. In particular it seems you have to use "Step into instruction" (with the appropriate key, or holding ctrl while hitting the step button) a lot if nothing happens, and to see registers and so on you have to use the gdb command line within the Xcode windows.
Remove the particular file and add the file again. This fixes my problem.