Debugging Lab Activity

Before You Start…

Form a group of about three or four people.

Then do the following:

1. Pick a lab machine to work on. Make sure that you're all able to see the screens and potentially take over the keyboard.
2. Find out your group number. Prof. Melissa will hand out a piece of paper with your group number on it.
3. Have one person in the group open Visual Studio Code, and then sign into the course server.

4. Choose the Open Folder option and select and navigate to either

   • /cs70/fall2025/lab/debugging/sect1/groupN (for section 1), or
   • /cs70/fall2025/lab/debugging/sect2/groupN (for section 2).

   (Replace N with your actual group number, and note the leading slash; this code is not in your own directory.)

New Help Pages!

As your code gets more complex, debugging becomes more important. These are some (new!) help pages that you might find useful:

• Using Assertions
• Debugging Strategies — this one is our main focus for now
• Using GDB

Group Activity, Part 1: Mindset and Tools

Read over the first two sections of the Debugging Strategies help page to learn about the debugging mindset and some useful tools. In particular, be sure you can explain the expanding island of certainty principle to one another.

Group Activity, Part 2: Role Play

The next part of the Debugging Strategies help page describes an imagined scenario where a student team is trying to debug a piece of code and a grutor is helping them out. Divide your group into two roles:

• One or two people will be the students trying to debug the code.
• It's probably helpful for those students to be the ones at the keyboard, using the server and VS Code, while having this page open in another window.
• One or two people will be the grutor(s) helping them out.
• It's probably helpful for the grutor(s) to have a separate laptop with the debugging page open, so they can refer to it as needed.

You can step out of your roles at any time to make observations about the process or share insights.

Our goal here is not the specific debugging of the code, but rather to practice the debugging mindset and strategies described in the help page. The goal is to exactly follow the story covered in the help page, while also thinking more broadly about what is going on, and how what is being done helps to resolve the issue.

View, Compile, and Run the Code

Briefly look over find42.cpp to see what it's supposed to do. Then run

clang++ -g -Wall -Wextra -o find42 find42.cpp -lranduint32
./find42

(If you like, you can experiment by showing that the program doesn't crash if you try to find 0 instead of 42, but be sure to reset the code back to looking for 42 before continuing.)

Debugging Role Play

Grutor(s): Suggest a way to learn more about what happened when the program crashed.

Everyone should look at the new evidence, and the grutor(s) should guide the students through the process of interpreting it.

Grutor(s): Suggest adding an assertion to check to see that the index is valid.

Recompile and rerun the code, and look at the new evidence.

Students should continue to be perplexed by the behavior of the code and wonder if somehow the array doesn't receive any of the numbers written to it.

Grutor(s): Suggest a way to learn more about what the code is doing (following the same steps as in the help page).

        // Check that the index is valid
        assert(i < v.size());

        // Check that the number was actually added, two ways just to be sure
        assert(v.back() == num);
        assert(v[i] == num);

        if (num == 42) {
            std::cerr << "- Added 42 at index " << i << "\n";
        }

    std::cerr << "Trial " << trial << ":\n";

    std::cerr << "Array contents: ";
    for (size_t i = 0; i < v.size(); ++i) {
        std::cerr << v[i] << " ";
    }
    std::cerr << "\n";

After the grutor(s) have guided the students through the process of gathering more evidence, interpreting what you've found, and forming and testing new theories, the students should now realize what the bug is and how to fix it.

Reflect

After the role play, take a few minutes to reflect on the experience. Discuss the following questions with your group:

1. What's the benefit of adding assert statements to your code?
2. Overall, what are we trying to as we debug code?
3. Anything else you want to share about the experience?

Group Activity, Part 4: A Glimpse of GDB

We don't require you to use GDB (the GNU Debugger) in this course, but it's a useful tool to know about, and in particular, it's good to know enough to know whether you want to learn more about it. So we'll take a few moments to do one more experiment.

In the work directory there is another source file, find54.cpp, that is identical to find42.cpp, except that it searches for the value 54 instead of 42 and doesn't have any of the debugging-process changes you just made.

(It will help to make your terminal in VS Code a bit taller so you can see more lines at once!)

Compile it and run it and it will crash:

clang++ -g -Wall -Wextra -pedantic find54.cpp -o find54 -lranduint32
./find54

Now, instead of running valgrind, let's run GDB:

gdb ./find54

Once GDB is running, run the following commands:

run

Start the program running; it will crash.

bt

Show the backtrace of the program at the time of the crash. Look at the report to see which frame contains code that you recognize rather than code from the C or C++ standard library (i.e., code mentioning find54.cpp).

f 7

Switch to frame 7, which should belong to the find54 function.

list

Show the source code around the current line.

p index

Print the value of the local variable index.

p v

Print the value of the local variable v.

quit

Exit GDB. (Say y if it asks you whether you want to kill the program.)

What do you think? As a group, discuss whether you think GDB is a tool you might want to learn more about.

(When logged in, completion status appears here.)