Debugging

Your code doesn’t work as you expect it to. Now what?

To debug properly, you need to systematically compare your expectations of what SHOULD happen to what ACTUALLY happens. You should validate each expectation one by one to narrow down exactly where it’s going wrong.

As an example, suppose your ship doesn’t appear to be moving. Here’s an example of how you might go through the process of debugging:

1. “I expect that MoveComponent::Update is called once per frame.” Is it? Put a breakpoint at the start of the function. If it’s not getting hit, then that means it’s not being called.
2. “I expect the code in MoveComponent::Update updates the position of the actor”. Is it? Use variable watches and step through the code. What’s the actor’s position before your code runs? What about after the code runs? Do the values before/after seem sensible and reasonable? (As an aside, using temporary variables may help with debugging as it’s easier to see the values in the debugger).
3. If you got through step 2 and it seems reasonable but still doesn’t work, then the next expectation might be “I expect only MoveComponent::Update is changing the actor’s position.” One way to validate this assumption is to continue past the breakpoint to the next time the function gets hit. Did the change you made persist, or did it reset to a different value? If it reset to a different value, and you’re not sure where it might’ve changed, you can us a conditional breakpoint (see below).

When posting on Piazza or asking questions in office hours, the more debugging legwork you do beforehand, the more we can help you. If you just say “it doesn’t work” and that’s it, we will ask you to do some debugging before helping. Please read the office hours expectations for more information.

Using the IDE’s Debugger

Using your development evironment’s debugger is a very important programming skill as it allows you to trace through your code to figure out where it’s going wrong. Although different IDEs like Visual Studio or Visual Studio Code may have slightly different user interfaces, the overall process of debugging and most terminology is similar.

If your previous experience using the debugger is exclusively through GDB, you’ll be relieved to know that debugging in Visual Studio or Visual Studio Code is much more user-friendly than debugging in GDB. Don’t feel bad if you dread using GDB, as even your professors do not like using it!

Visual Studio (PC)

To learn the basics of how to use the debugger in Visual Studio, you should first go through this tutorial.

Once you’ve completed the tutorial, if you want further information, there is a lot of great documentation about the debugger in Visual Studio, such as:

• Navigate through code
• Use breakpoints
• Inspect variables
• View the call stack

Visual Studio Code (Mac)

Remember that to launch your game in debug mode, you need to click on the bug button on the bottom toolbar:

Read the following to learn about the most important debugger features:

• Debug actions (how to step through code)
• Breakpoints
• Data inspection (viewing variable values when paused in the debugger)
• Conditional breakpoints

If you read further in the debugger documentation, you’ll see there’s a lot of information about setting up your launch.json configuration in Visual Studio Code, but you should not need to mess with those in the class as the bug button allows you to “quick-debug” the CMake target without needing to setup a launch.json file.

---