CMPSC 311 Debugging Questions

(True or False): To use GDB effectively, you must compile your program with the -g flag to include debug symbols.

True - The -g flag tells GCC to save debug symbols with the program, which allows GDB to map binary code back to source code. Without this flag, GDB cannot effectively show you which lines of code are executing

(True or False): Print debugging is never used by professional developers because debuggers like GDB are always more efficient.

False - Professional developers often use print debugging for quick bug identification and fast iteration. The choice between print debugging and using a debugger depends on the complexity of the bug and time tradeoffs. Both have their place in a developer's toolkit

(True or False): A breakpoint can be set on a function name, but not on a specific line number.

False - Breakpoints can be set on both function names and specific line numbers using commands like b factorial or b 16 or b debugging.c:18

(True or False): The next and step commands in GDB do the same thing.

False - next steps over function calls, executing them completely and stopping at the next line. step steps into function calls, allowing you to debug inside the called function

(True or False): Once a variable's value is set in a program, GDB cannot change it during execution.

False - GDB allows you to modify variable values during execution using the set variable command (e.g., set variable x = 10). This is useful for testing different execution paths without recompiling

(True or False): A watchpoint stops execution when a variable's value changes, regardless of where in the code the change occurs.

True - Watchpoints (data breakpoints) monitor a variable and halt execution whenever its value changes, without requiring you to know the specific line where the change happens. This is useful for tracking down unexpected modifications

(True or False): The backtrace (or bt) command shows you the current call stack and where you are in the program.

True - The backtrace command displays the stack trace showing all function calls that led to the current point of execution, along with line numbers and parameters

(True or False): Debug symbols increase the size of executables, which is one reason why the -g flag is opt-in rather than default.

True - Debug symbols add significant metadata to executables. Production releases typically exclude them to reduce file size and prevent reverse engineering. The -g flag is opt-in so developers can choose when to include this extra information

To print a backtrace of your stack you can use:

• A) which frames

• B) where / bt

• C) watch

• D) show backtrace

• E) info locals

B) where / bt - Both where and bt (backtrace) display the call stack showing all function calls that led to the current execution point, along with line numbers and parameters. watch creates watchpoints, info locals shows local variables, and show backtrace / which frames are not valid GDB commands

Which of the following statements are true?

• A) watch i stops when i changes

• B) cond 1 i<=1 makes existing bp #1 conditional

• C) info breakpoints lists all breakpoints

• D) b 7 if i<=1 sets a conditional breakpoint

All statements (A, B, C, D) are true - watch i creates a watchpoint that halts when variable i changes. cond 1 i<=1 adds a condition to existing breakpoint #1. info breakpoints displays all set breakpoints with their details. b 7 if i<=1 creates a conditional breakpoint at line 7 that only triggers when i<=1

To print a variable in hex format you use:

• A) p hex var

• B) p/x var

• C) p/t var

• D) hex var

B) p/x var - The /x format specifier tells GDB to display the value in hexadecimal. Other format specifiers include /t for binary, /d for decimal, and /o for octal

Which command would you use to see all currently set breakpoints?

• A) list breakpoints

• B) show breakpoints

• C) info breakpoints

• D) print breakpoints

C) info breakpoints - The info command provides information about various aspects of the debugging session. info breakpoints lists all breakpoints with their numbers, locations, and conditions

When debugging a loop that runs billions of times and occasionally crashes when variable i becomes negative, which approach is most efficient?

• A) watch i

• B) b 840 if i < 0

• C) watch i < 0

• D) b 841 if i < 0

D) b 841 if i < 0 - A conditional breakpoint at the start of the loop body (line 841) that only triggers when i < 0 is the most efficient. This avoids the overhead of checking every iteration (like watch would) and only stops when the problematic condition occurs

To continue execution until the current function returns, you would use:

• A) continue

• B) return

• C) finish

• D) next

C) finish - The finish command continues execution until the current function returns. continue runs until the next breakpoint, return forces an early return, and next only advances one line

What does the command cond 1 i<=1 do?

• A) Creates a new conditional breakpoint

• B) Makes existing breakpoint #1 conditional on i<=1

• C) Checks if condition i<=1 is true

• D) Continues execution if i<=1

B) Makes existing breakpoint #1 conditional on i<=1 - The cond command adds or modifies a condition on an existing breakpoint. Breakpoint #1 will now only trigger when i<=1 is true

Which GDB command lets you move up the call stack to examine the calling function's variables?

• A) step

• B) up

• C) next

• D) back

B) up - The up command moves up one level in the call stack (toward the calling function). down moves in the opposite direction. This allows inspection of variables at different stack frames without affecting program execution

Explain the difference between breakpoints, watchpoints, and conditional breakpoints in GDB. When would you use each?

• Breakpoints halt execution at specific code locations (functions or line numbers).

• Watchpoints halt execution when a variable's value changes, regardless of location.

• Conditional breakpoints only halt when both a location is reached AND a condition is true.

• Use breakpoints for known problem locations, watchpoints for tracking unexpected variable changes, and conditional breakpoints for bugs that only occur under specific conditions (like when a loop counter goes negative).

Why is debugging considered the most time-consuming part of programming, and how does using a debugger like GDB potentially save time compared to print debugging alone?

Debugging is time-consuming because you must figure out where your code diverges from your intentions, validate assumptions, and track down bugs that may only appear under specific conditions. GDB saves time over print debugging for complex bugs by allowing you to: inspect state without recompiling, step through code line-by-line, examine the call stack, set conditional breakpoints that only trigger when needed, and modify variables mid-execution to test different scenarios. For simple bugs, print debugging may be faster, but GDB becomes essential for complex issues.

Explain what the assert() function does and why it's considered "defensive debugging" rather than true debugging. In what situations would you use assert statements in production code?

assert() checks that an expression is true and aborts the program if it's false. It's "defensive debugging" because it validates assumptions and catches bugs early rather than helping find existing bugs. Asserts are typically used to check preconditions (like non-NULL pointers or valid input ranges) and invariants that should always be true. In production code, asserts can be disabled with NDEBUG, so they're best for catching programmer errors during development rather than handling expected runtime errors, which should use proper error handling instead.

Explain what rubber duck debugging is.

Rubber duck debugging is the practice of explaining your code line-by-line to an inanimate object (traditionally a rubber duck), another person, or yourself. The act of verbalizing your logic forces you to slow down and articulate what you intended versus what you actually wrote, often revealing bugs in the process. This can take the form of talking to yourself, talking with a colleague, slowly reading code statement by statement, or drawing out code relationships. It works because explaining forces careful examination of assumptions that might otherwise go unquestioned.