Hello and welcome back.
In this lecture, I want to go through a demonstration of how you can use the debugger.
So I want to run through the graphical user interface, show you how you can start up a program in debugging
mode, how you can set breakpoints, how you can look at the call stack and how you can view different
variables using the watch window.
Just a simple program that's determining an average.
I'm going to use this as my demonstration.
All it does is it reads in three integers and stores them and then computes their average.
Now, one thing I want to mention before we actually using the debugger, you have to make sure that
your configuration is set up correctly.
And I have talked about this in a prior video, basically configuring code light for using the debugger.
But just to refresh your memory, you can select the project here, you can right click and you go to
settings.
You want to make sure again, depending on what platform you're on, you want to make sure that the
debugger settings here on the left have the right path to GDB.
Now if you're on Windows that may entail using GDB X from Cygwin or it may be using the MinGW w64,
whatever you got working.
If you're on Unix and Linux, this path doesn't even necessarily need to be set.
The other important thing is in the compiler options you want to make sure that you're compiling for
debugging so that Dash G dwarf is on dash o for optimization.
Again, in Windows, those things have to be set in order to have debugging information along with your
executable.
You also have to make sure that you're building for debug mode.
So you've got to make sure that debug is selected and not release.
Once you have all those things configured correctly, you should be able to use the debugger and code
light.
If you have any issues with that, go please go back to my video for configuring on your platform.
The Debugger and Code Light.
The most important concept concerning the debugger is the idea of a breakpoint.
And so a breakpoint is something that you can set in your program where it will stop execution of your
code.
You can essentially say, Hey, I want to stop at this line and your program when you run the debugger
will stop at that line That allows you to look at variables, the values of variables.
It allows you to step through your code one line at a time to try to diagnose and fix any problems that
may have.
Normally, when you run your program, if you try to run it in the debugger and you don't have a breakpoint
set, nothing's going to happen.
So normally when you build, you know, you can go and you can build your project just like any other
project, go to build, go to build project.
When you build it and run it in debug mode, you have to go up to the debugger menu option and you have
to go to start, continue debugger.
And when you execute that again, if you have a breakpoint set, it will hit it.
If you don't have a breakpoint set, it will just run.
So if we try to execute this program in debug mode, it just comes up and asks for enter because it
stops right at the numbers and then you just hit some numbers in and it just closes down.
It doesn't even actually print out the information, right?
So it's very important if you want to use the debugger that you have at least one breakpoint set.
The easiest way to set a breakpoint is to simply click inside the margin by the line numbers on the
line number that you want to set the breakpoint.
And again, a breakpoint is going to stop execution on that line number.
So if we set a breakpoint right by the printf function on line ten, we just double click, you'll see
that a red circle gets placed.
This is telling the debugger, hey, stop at line ten.
So again, the way that we start the debugger is we go up to debugger and we say, start, continue,
right?
Everything else is kind of grayed out, right?
So let's just start the debugger just to hit that breakpoint.
So let's go start to continue the debugger and we'll say build and debug and you'll notice that the
program stops at line ten.
You see that green arrow, You also see that the debugger pane came up.
So if you go to view, you can actually bring up the debugger pane manually or it can automatically
come up when you go into debug mode and the debugger pane has many different tabs for information that
can be seen.
You can also go through it through the debugger you go to GDB windows, you can see all the ones that
are checked.
There are many debugger windows that you can look at.
So locals usually has to do with your local variables watches.
You can put a watch on a variable so that if the variable changes it will pop up.
Output is for use for different debugging options and output threads.
You can actually look at the threads that are running your program.
More advanced concept Callstack is what we focus on.
We basically look at the call stack and the locals.
Those are the two most important ones that help you with debugging and then memory and then also breakpoints.
You can see where the breakpoints are set.
So a lot of different options.
We're currently stopped at line ten.
We can look at the call stack.
The call stack shows us that the main function is called.
If we look at locals, it shows us three variables zero one and zero.
We haven't actually entered any information in those are initialized zero one and zero.
The watch is you can actually add.
Add by hitting the plus sign to add a watch on a particular variable.
And then the other important thing to notice is when you run in debug mode, you now have the toolbar
for the debugger, right?
The play button will just continue.
So it will go.
If I hit play, it will just exit the program, right?
It will just start running.
The program actually will ask for input.
So I hit play.
I go back to the console application and it says Enter.
So I hit my three numbers in the program runs.
Then you still didn't see the print function.
The window just went away.
So again, we run in debug mode and it goes to the breakpoint again, the debugger pane comes up, it
stops line ten.
Now the toolbar is important because this is how you can actually step through your code and you can
actually use the toolbar or you can go up to the debugger and you can look at all the options up here.
So you can say step into step into instruction next, next instruction, step out, step into will go
inside of a function.
If a function is being called on that line, step into instruction goes more to the assembly language
type stuff.
Next, we'll jump over that line of code next.
And neck instruction are kind of the same thing.
Step out, tries to jump out of a function if you're already in one and jump to the carrot line.
Actually I think goes to the cursor.
The same with run to the carrot line.
You can turn breakpoints on and off, disable them all, all that stuff so you can access this through
the menu.
Or again, the toolbar.
Usually I use the toolbar because it's already up.
And then if you look at the different windows again, locals call stack and breakpoints.
Really those important ones.
This says I have a breakpoint at line ten.
And then I think one just says the cursor.
So now I've stopped here at print F enter on line ten.
I can go to the next instruction and this will go to line 11 scan.
F is actually a blocking function that asks for input.
So if I try to go next here, it actually just kind of pauses.
You might actually have to hit next multiple times.
What I usually do when the program is asking for input and I want it, it's already blocked, it's already
stopped and I want it to go to the next.
I'll just put a break point on that next line and hit the play button.
So now I hit the play button and nothing's happened because it's waiting for input.
In the program it says Enter.
So here I can hit five, six, seven, hit the enter button and now it hits my break point.
So now we're at the print button where we can actually jump into the print function.
And actually first it will jump to the average function.
So if we say step into we see we go to the average function.
And what you'll notice is if you look at your variables, you can kind of see your variables changing.
So if you go next, you go to the next line in 27, then 28, and then keep hitting.
Next, you actually jump out and you're actually at the end of the function.
So then you can hit play and you can see that your program has now completed and the window went away.
But you can look at your variables, you can look at everything else.
And so, again, you can also put a break point inside the print function right here.
And if we run to that, we can see again that the print function will stop execution instead of the
average.
And then we can kind of see what's going on in the actual if we step over
and we go to the application, you can see that the information was printed out.
Right?
When you continue, when you run to the end, you get the return statement and the program will exit.
So it's important if you do want to see the output of the program that you place a break point before
that return and you don't have to continue.
You can stop the debugger by hitting that red rectangle, pause the debugger by hitting the two parallel
bars, restart the debugger with that option and the callstack.
Again, it's easier to see here if you get inside of a function and you run the debugger, we'll run
the debugger again.
Say debugger, start, continue.
And when we hit that break point after entering information inside of a function, you'll see the car
stack has the main and the print just like we showed before.
And so you can see the last function that was invoked now with a program that has many functions and
so forth, the call stack can get much larger than this.
The only other thing that may be important is the breakpoints.
If you want to see what breakpoints you set, it will show you all the breakpoints and your entire program
where they're located.
But you'll have to play around with this, get familiar with it, get comfortable with it, and use
it quite often for problems that you can't figure out with basic debugging techniques or programs.
Crash go line by line.
And as you go line by line, you can actually see the program exit once it crashes and you would know
what line that occurred on.
Again, this is a small program, but you should get the basic understanding of how debugging works.
Again, I hope this was helpful.
The best way to learn this stuff is to start playing around with it and start using it.
Bring up one of the programs that you were that worked on in your previous challenge.
Add a break point, very simple.
Just click right inside the thing to add break points.
Start it up in debug mode and step through each line and see how the variables change and how the call
stack increases.
If you have bigger functions.
Thank you.