Introduction to the "steps" of a debugger? [duplicate] - debugging

This question already has answers here:
What is step into, step out and step over in Firebug? [duplicate]
(4 answers)
Closed 8 years ago.
Step Over, Step In, and Step Out.
I want a better understanding of what to expect when pressing these buttons in a debugger.
There are a lot of language & tool specific debugger entries, but I couldn't find a generic explanation of the feature.

Simply put, this is how you advance ("step") through your code via the debugger, one line at a time. Here's an example of using Visual Studio debugger.
Suppose you have the following code:
public static void Main(string[] args)
{
int x = 4;
M(x);
}
private static void M(int x)
{
Console.WriteLine(x);
}
Suppose you put a breakpoint on the M(x) line. When the debugger stops ("breaks"), you now have 3 options:
1. Step Over (F10)
If you press F10, you will step over the line M(x). The debugger will execute this method, but you will not go into it. On the console output, you will see 4.
2. Step Into (F11)
If you press F11, the debugger will take you inside the M() method, allowing you to single-step (with F10 or F11) inside the M() method. If you keep pressing F11, you will enter additional methods (provided you have their source code available)
3. Step Out (Shift-F11)
Instead of single-stepping one line at a time, you can press Shift-F11 to step out of the current method, and return to the calling method. In this case, if you press Shift-F11 while inside the M() method, you will be taken back to the calling Main() method.
I hope this makes it clearer.
P.S. This is not Visual Studio specific, but a general concept of debugging. With the debugger, you always single-step over instructions, be that lines of code or assembly instructions. Step over/in/out are concepts you will find in every debugger, and they all mean the same thing.
There are additional things some debuggers allow you to do, such as Run to selected line. Here's more info about Visual Studio debugging capabilities: http://msdn.microsoft.com/en-us/library/y740d9d3.aspx

This will be IDE specific, so your question is targeted as being too broad.
But in general, this is what these terms mean.
When debugging code, if the current line is the call to a function, let's call it M(y).
If you Step In, then the debugger will start stepping into the function M(y).
If you chose Step Over, then the function M(y) will be executed and the debugger will stop at the next line after the call of the function M(y).
Step Out only works if you are already inside of M(y). Let's say you are in the middle of M(y) and you realize the bug is not there, and you'd like to continue on the first line of code after the call to M(y). That's when you pick Step Out.
Again, this will vary from IDE to IDE, but on my experience (more than 11 IDEs) this is the standard behaviour.

Related

Create a visual studio breakpoint that pauses for one second and then continues

The topic says it all. Sometimes i just want to take a quick look and then continue, especially when a code line get hit several times. Can i automate the press-manually-f5-to-continue-after-a-second?
Right click on a breakpoint an select "When Hit...":
You can run a macro like this:
Sub Sleep1s()
System.Threading.Thread.Sleep(1000)
End Sub
Or you can call 11 times {System.Threading.Thread.Sleep(90)} in the message. (Because VS debugger doesn't allow for expression to run for more than 100 ms).
But sleeping this way will block the main IDE UI thread. I don't know is it acceptable for you.

Automatic Step over in Xcode

I was debugging my code and thought about a possibility of automatic stepping over or Step into line by line in the xCode debug mode. It would be more efficient to see the way the code will be executed line by line without clicking for every next step. Maybe theres a way you can set a timer for every next step.
I was searching for something like that but there are too many posts for the debug mode which just explain the basic stuff.
Maybe I'm not understanding the question, but the three key buttons are:
- "Step over", F6, continuing execution but stopping at the next line of code (but not single stepping through the method that the current line of code references);
- "Step into", F7, continuing execution but stopping at the first line of code in the method your current line of code references;
- "Step out", F8, continuing execution but stopping at code that called current method.
See Control Program Execution of the Xcode Users Guide.
The other obvious technique is judicious use of setting breakpoints or setting "watch point" (i.e. have the debugger automatically pause whenever a particular variable changes).
Probably worth seeing Debugging in Xcode WWDC 2012 video

Visual Studio 2010 - how to skip a method execution druing debugging

I have a method that is executed multiple times (reading data from a database) and now I need to debug a code that executes this method and it seems that it is executed until it reads all rows from the table (1000+) I just want to let the program execute this method and continue with the debugging from there.
Just to be more specific - in debug mode I use F11 to go through the code and this behavior is frustrating. I don't want to change my break point, just want to let this method executes itself, but the only way I know for now is pressing F5 which executes everything not just the current method.
Two options:
1. Press Shift+F11 to step back out of the function
2. Once you have stepped into the function, insert another breakpoint immediately after the loop, then press F5 to skip to that breakpoint.
You can decorate your method with [DebuggerStepThrough]
Instead of using Step Into (F11) Use - Step Over (F10)
and if you've already entered the function (because you pressed F11) you can always Step Out using Shift + F11
For more information see Mastering Debugging in Visual Studio 2010

What is the use for the Step Over Thread and Step Into Thread commands?

Can someone explain what is the purpose of the Step Over Thread and Step Into Thread debugger commands in Xcode? In what case is it useful to use them rather than the usual Step Over and Step Into? What is the difference and when does it matter?
Edit: To clarify the question, I'm not asking about the difference between Step Over/Step Into/Step Out, I'm asking about the difference between the normal and the "Thread" versions, and in what case one version is more useful than the other.
Step Into
Executes the current statement and then stops at the next statement. If the current statement is a function or script call, then the debugger steps into that function or script, otherwise it stops at the next statement.
Step Over
Executes the current statement and then stops at the next statement. If the current statement is a function or script call then the debugger executes the whole function or script, and it stops at the next statement after the function call.
Step Out
Steps out of the current function and up one level if the function is nested. If in the main body, the script is executed to the end, or to the next breakpoint. The skipped statements are executed, but not stepped through.
Argument is general About debugging so look at
What is the difference between Step Into and Step Over in the Eclipse debugger?
Looking at specific the focus is thread so you can look at your "multithread" application as single thread application without having multiple events/thread etc. running while you are stopped at break point. You have a "stable enviorment".
http://developer.apple.com/library/ios/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/060-Debug_Your_App/debug_app.html
I just struggle with the same question. Question is a bit old but it looks like I found the proper answer.
Here in documentation, I found something like that:
Control-Shift to step into or over the active thread only while holding other threads stopped (the step icons show a dashed rather than solid line below the arrow).
Control-Shift-<Fx Key or click> are respective shortcuts for thread versions of step over and step into. So it looks like that this executes only current thread and suspending temporary all other threads. Normal versions continues execution of all not suspended threads.
a very simple explanation of this term:
Step Into, Step Over, Step Out Commands (Debug Menu)
According to this book:
Step Over Thread and Step Into Thread freeze all other threads while you advance the thread you're debugging. Hold down Shift and
Control while clicking the buttons, or select the commands in the
Debug menu, to get the effect.

How can I force VB6 to enter the debugger from the execution of a program without a break point?

I'm trying to watch the execution of a VB6 app and I'm running into an issue because once I enter the debugger and then hit Continue, it no longer lets me step through the code until I hit another break point. I want to be able to execute a program without stepping through something until I hit a point where I want to watch it execute. Ideally this would be something to the effect of holding a key down while I pressed a button to 'step into' that function.
Thanks in advance!
[EDIT]: I'm aware that I can use break points to stop the execution. To be more clear, the problem is that I don't know where the execution is going to, so I can't set the break point there (because I don't know where there is). That's why I essentially want to be able to say, 'after this next thing that I do, break, no matter what'. It sounds like this functionality does not exist, but I'm still keeping my fingers crossed.
While the code is running, press ctrl+break (or the 'VCR pause' button in the IDE) then press F8 (or choose 'Step Into'from the Debug menu in the IDE) to continue running the app. The next action will cause execution to break.
Note that the which causes the break will not always be the one you hoped it would be. Particularly annoying is the _MouseOver event which prevents you from doing a mouse down or a timer firing quckier than you can perform your action. Some breaks may even be fatal as regards running your app e.g. where Windows messages have been hooked (subclassing). Also consider there may not be an event handler in code (yet) for your action where it can break. But usually this technique identifies where you should be setting your breakpoint.
There is a Stop statement available for use in VB6 that will drop to the debugger when the statement is executed from code running through the IDE. (Just be sure to remove the all of the Stop statements from the code when compiling a release build.)
There are several techniques you can use.
These two have been mentioned
Using F8 and Shift-F8 to step through the program
Adding Stops (and later removing)
Others
Use a global variable to create a collection. Use it as a stack and have the subroutines you are interested in push and and pop strings. Conversely don't pop anything and you will get a trace.
Use Watches to monitor and break at selection conditions. You can setup just about any condition to break.
Make a Global String and have your procedures set when you enter them. Monitor it through a Watch.
Use Debug.Print in your code. Also Unlike Stop you can leave these in without effecting the production code.
Use the File System Object to create a text file to act as a log.
Sometimes problem only occurs in the Complied version then you need to use MsgBox or log to a text file. MsgBox can alter the behavior of complex user interactions with forms.
These are all techniques I used in debugging an application. If I had to monitor an application I would use Debug.Print. If that doesn't do the trick compile then log to a text file.
If you have something really complex going on then I recommend moving all your code out of the events into classes implementing a Command Pattern. Your commands classes should interact with the form through and interface.
In the Execute method of the command classes you will something like
<save the current state>
<Do your original code>
<save the modified state>
<push the command onto a stack>
What will happen is that you wind up with a list of all the commands you have executed (even things like mouseover) with the state they encountered and the modified state. You can then examine each object in turn to see what is happening. This is nearly the equivalent of creating Undo/Redo
Note however things like MouseOver can push a lot of classes on the command stack so you will have to structure your tests carefully or be overloaded with information. Remember you can always skip pushing the command onto the stack.
The downside of using commands is that you gone beyond debugging into redesigning. You will to decide whether the problem is worth doing this.
You can press the F8 key to step through the code line by line. Alternatively, you can press SHIFT-F8 to step through line by line.
F8 will step you in to a function, where SHIFT-F8 will step you over the function. If you click on the DEBUG menu in the VB IDE, you will see other options too.
EDIT:
You can also put a permanent break point in your code by using:
Debug.Assert False
By doing it this way, the 'breakpoint' is saved in your code. When you compile the app, debug code is ignored.

Resources