In this lab, you’ll practice using VS Code’s C debugger.

The images in this lab are from Windows. The Mac and Linux versions of VS Code look similar to this, but not identical, so you should adapt accordingly.

What’s a debugger?

A debugger is a tool designed to help you debug your programs. Debuggers tend to have a lot of sophisticated features, but the core of what you need to know is this: a debugger allows you to run your program one line at a time, enabling you to examine your variables along the way. If you can watch your variables evolve one slow line of code at a time, you can usually track down your errors.

Setting breakpoints and inspecting variables

To get started, launch VS Code and connect to mantis. Go back and look at Lab 1 again if this process isn’t yet ingrained in your memory.

Now, let’s get started debugging:

• Install the C/C++ Extension Pack: Select the View->Extensions menu, search for the C/C++ Extension Pack from Microsoft, and install it.

• Get a program to debug: Copy the debug_this.c sample to your working directory on mantis. You can do this using File->New Text File and then copy-pasting the contents. (Alternatively, you can use your mantis terminal and a variant of the wget command described in the Starting C assignment to grab debug_this.c—it’s good to be comfortable using either approach.)

• Read the code: Take a look through debug_this.c and see if you can spot the bug. Either way, run it and observe the bug. (Yes, it’s a simple one to fix, but let’s leave it be for now.)

• Set a breakpoint: Once you have a copy of debug_this.c open in VS Code, scroll down to the function iterative_triangular_number. At the line with the for loop, hover your mouse to the left of the line number. You will see the ghost of a red dot. Click it to make that red dot solid.

When you run the program in debugging mode, the program will stop just before executing the line of code at your breakpoint.

• Start debugging: You can do this either from the Run menu or from the play-button-with-a-bug in the upper-right corner of VS Code.

Your program will stop when it first gets to your breakpoint.

• Look around for a minute: In the code, the line at your breakpoint is highlighted. This line has not yet executed.

There’s a debugging toolbar at the top with different debugging buttons, including a continue button to let your program continue from where it left off and a stop button for stopping the program. Hover over the buttons to see their names (and keyboard shortcuts).

There is also the terminal/console display at the bottom of the window, showing that the program has already produced some output,but is stopped halfway.

Most important of all, in the upper-left corner of the VS Code window, there is the Variables panel, showing you the current values of the variables k and total, as well as the parameter n. Note that k hasn’t been initialized yet, so it may have some (seemingly) random value.

Finally, in the bottom left, there’s the Call Stack. What do you think this is?

• Step through your code: When the program stopped at your breakpoint, you were in the middle of iterative_triangular_number(1) (how can you tell?). You can now step through your program one line at a time.

  • Click the Step Over button in the debugging toolbar.

  • Look at the Variables panel. Did the variable values change the way you expected them?

  • Repeat until the program returns to main. Go slowly and pay attention to what changes after each click of the Step Over button.

  • Keep going until you’re at the line in main when iterative_triangular_number(2) is about to be called. Now, instead of clicking Step Over, click the Step Into button.

  • Keep doing this as long as you want (or until you observe the bug).

It is extremely valuable to be able to step through your code slowly to see whether it’s doing what you expect it to do. Get in the habit of doing this when you have a bug, but also even when you think your code is working. You can find a lot of subtle bugs this way.

• Done debugging: You can stop by clicking the Stop button. You can get the File Explorer pane back via the View->Explorer menu or clicking the appropriate button on the far left.

• Fix the bug: Now that you’ve found the bug, you can fix it! Do so, then click the red dot by line 45 to remove your breakpoint, rerun your program, and observe that it is fixed.

Debugging with command-line arguments

Get a copy of character_counter.c into your mantis working directory. Recall that this program requires a command-line argument. This section walks you through providing that argument to the debugger.

• Open character_counter.c in VS Code.

• Open the “configuration” file for your debugging session. Note that if you don’t have one, you’ll have to select Add Configuration....

• Here is what my config file looks like. Yours will likely be similar, or you can copy down these lines:

• Create a small text file for character_counter.c to work on. Here is mine:

• Edit (and save) the config file to enter your command-line argument.

• Open character_counter.c and run it in the debugger. Does it work? (Note: I’ve had differing luck with the menu option, the far-left play-plus-bug button, and the top-right play-plus-bug button, so if one isn’t working, try another.)

A few more things to try

Here are a few more things to try out and ponder. It will be really helpful to you later to get comfortable using a debugger now, so I encourage you try them now, and revisit them if you’re having any issues later! You can also ask about these in office hours if there is anything I can help clear up.

• In debug_this.c:

  • Comment out everything in main except the return statement.

  • Add a call to recursive_triangular_number(10) and a print statement to print out its result.

  • Put a breakpoint somewhere in recursive_triangular_number.

  • Run the debugger.

  • When you hit the breakpoint, take a look at the Variables panel; is it showing what you expect? Also, look at the Call Stack panel; is it showing what you expect?

  • Click the Continue button. You should land at your breakpoint again. How have the Variables and Call Stack panels changed? Repeat this a couple of times.

  • Now, you should have quite a few function calls showing in the Call Stack. Click on each of them, and when you do, look at the Variables panel. What changes as you click on each function call? Explore, experiment, etc.

  • How would you explain the Call Stack to a CS 111 student?

• What is the difference between the Step Over and Step Into buttons? Test this. Also, what happens if you try to Step Into a C library function like printf?

• What if your program requires more command-line arguments? What syntax do you use in the launch.json (config) file?

• Declare an array in main or some other function and break somewhere in that function. What does the array look like in the Variables panel?

• Put a breakpoint in character_counter.c’s main just before get_character_count gets called. When your program hits that breakpoint, take a look at the input_file_name variable in the Variables panel. Make sure your Variables panel is wide enough that you can see both the numerical/address value of input_file_name as well as the string that it points to.

That’s it!

There is a lot more to learn about using a debugger, but this should give you a good start. Keep practicing, and as always, ask questions you may have!