Every so often, when I'm debugging and stepping through a thread, Xcode pulls me into another thread (that I'm guessing is executing all the other stuff involved in setting up views etc.). the problem is that this doesn't help me, as I just want to observe the code I've written myself.
Is there any way to prevent this?
If you use "step over" you normally won't see this view, I only ever see it when I do "step into" on lines with a compound statement.
What you are seeing is not your code, but the debugger working through code it doesn't have the source to (e.g. UIKit stuff). If you hit "step out" or "step over" in this view, you will return to your code.
Related
Currently i'm on a project which has some main loop which is quite slow. Putting a breakpoint into it implicates i have to press F9 each time, and there are a lot of iterations. What i imagine is to see the program 'move' on one of my screens, without wondering if it is stuck or not.
I already have log outputs and so on, my question really focuses on this 'show debug without stop' feature.
What i imagine is to see in this main loop the current line highlighted as i it was a line-by-line execution, but without breakpoints and without going down in the subcalls.
Does any of you know a way to do something like this or wish the same thing ?
Thanks !
Your Debug tool window has a "Mute breakpoints" control:
If you leave it ON, your application won't stop at breakpoints. You can switch it off later once you reach the point where you actually want to start debugging (e.g. mute breakpoints while the app is doing all the initial loading tasks, while you navigate to the screen you want to debug etc. and then unmute them).
I'm not quite sure this is it but , how about disabling focus on breakpoint:
Put your cursor on the line you'd like to breakpoint and hit ctrl-shift-f8 (on a pc). You can choose not to suspend when a breakpoint is hit, and/or you can add logging that the breakpoint was triggered. If you need to, you can add a condition that must be met before the breakpoint is triggered.
Here's what this looks like for me:
I want to use the option of "step into" in the debugger. But, I want that the debugger enters only function that are implemented in specific files. For other functions, "step into" will behave like "Step Over".
You can use the debuggers stepping configuration to define where you want the debugger to stop and where not.
Or you can put a breakpoint to a start point from where you want to examine the behavior of your code and then put breakpoints in your specific files/implementations.
Furthermore, it would be very helpful if you describe your problem in more detail.
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! :)
Usually, this works, but in addition to my own code there a lot of machine code too, which doesn't really help me out with debugging my own program logic.
Is there a way to step through only my own code?
First put a breakpoint where you want to start step over.After the breakpoint ,Use this button to step over through the code.The play button just runs till the next breakpoint
You probably want to be using the next command or "step over" button in the debugger UI instead of step or "step into" to avoid stepping into each function as you debug. You might still want to step into your own functions, of course, but next will let you step over framework functions instead of diving into their assembly.
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.