Lecture Participation Poll #15

Log onto pollev.com/cse374

Or
Text CSE374 to 22333

CSE 374: Intermediate

Lecture 15: Debugging in C Programming Concepts and
Tools

1
Administrivia
Reminder: Midpoint Deadline Friday November 6th at 9pm PST
-Will post grades to canvas sometime the week after

CSE 374 AU 20 - KASEY CHAMPION 2

What is a Bug?
▪A bug is a difference between the design of a program and its implementation
-Definition based on Ko & Meyers (2004)

▪We expected something different from what is happening

▪Examples of bugs
-Expected factorial(5) to be 120, but it returned 0
-Expected program to finish successfully, but crashed and printed "segmentation fault"
-Expected normal output to be printed, but instead printed strange symbols

CSE 374 AU 20 - KASEY CHAMPION 3

Debugging techniques
▪Comment out (or delete) code
-tests to determine whether removed code was source of problem

▪Test one function at a time

▪Add print statements
-Check if certain code is reachable
-check current state of variables

▪test the edges

-code often breaks at the beginning or end of the loop, the entry or exit of a function <- double check logic here
-double check your logic in the odd/ rare exceptional case

CSE 374 AU 20 - KASEY CHAMPION 4

Debugging Basics
Debugging strategies look like:
▪Describe a difference between expected and actual behavior
▪Hypothesize possible causes
▪Investigate possible causes (if not found, go to step 2)
▪Fix the code which was causing the bug
▪Vast majority of the time spent in steps 2 & 3

CSE 374 AU 20 - KASEY CHAMPION 5

Hypothesize
Now, let's look at the code for factorial()
Select all the places where the error could be coming from
▪The if statement's "then" branch
▪The if statement's "else" branch
▪Somewhere else

int factorial(int x) {
if (x == 0) {
return x;
} else {
return x * factorial(x-1);
}
}

CSE 374 AU 20 - KASEY CHAMPION 6

Investigate
Let's investigate the base case and recursive case int factorial(int x) {
-Base case is the "if then" branch if (x == 0) {
-Recursive case is the "else" branch return x;
} else {
return x * factorial(x-1);
}
}

Case Input Math Equivalent Expected Actual

Base factorial(0) 0! = 1 1 ???

Recursive factorial(1) 1! = 1 1 ???

Recursive factorial(2) 2! = 1 * 2 2 ???

Recursive factorial(3) 3! = 1 * 2 * 3 6 ???

CSE 374 AU 20 - KASEY CHAMPION 7
Investigate
▪One way to investigate is to write code to int factorial(int x) {
test different inputs if (x == 0) {
return x;
▪If we do this, we find that the base case has } else {
a problem return x * factorial(x-1);
}
}

Case Input Math Equivalent Expected Actual

Base factorial(0) 0! = 1 1 0

Recursive factorial(1) 1! = 1 1 0

Recursive factorial(2) 2! = 1 * 2 2 0

Recursive factorial(3) 3! = 1 * 2 * 3 6 0

CSE 374 AU 20 - KASEY CHAMPION 8

Fix
int factorial(int x) { int factorial(int x) {
if (x == 0) { if (x == 0) {
return x; return 1;
} else { } else {
return x * factorial(x-1); return x * factorial(x-1);
} }
} }

Case Input Math Equivalent Expected Actual

Base factorial(0) 0! = 1 1 1

Recursive factorial(1) 1! = 1 1 1

Recursive factorial(2) 2! = 1 * 2 2 2

Recursive factorial(3) 3! = 1 * 2 * 3 6 6

CSE 374 AU 20 - KASEY CHAMPION 9

C Debugger
▪A debugger is a tool that lets you stop running programs, inspect values etc…
-instead of relying on changing code (commenting out, printf) interactively examine variable values, pause and
progress set-by-step
-don’t expect the debugger to do the work, use it as a tool to test theories
-Most modern IDEs have built in debugging functionality

▪‘gdb’ -> gnu debugger, standard part of linux development, supports many lan gyages
-techniques are the same as in most debugging tools
-can examine a running file
-can also examine core files of previous crashed programs

▪Want to know which line we crashed at (backtrace)

▪Inspect variables during run time
▪Want to know which functions were called to get to this point (backtrace)

CSE 374 AU 20 - KASEY CHAMPION 10

Meet gdb
▪Compile code with ‘-g’ flag (saves human
readable info)
▪Open program with gdb <executable file>
▪start or restart the program: run <program
args>
- quit the program: kill
- quit gdb: quit

▪Reference information: help

-Most commands have short abbreviations
- bt = backtrace
- n = next
- s = step
- q = quit
-<return> often repeats the last command

CSE 374 AU 20 - KASEY CHAMPION 11

https://courses.cs.washington.edu/courses/cse374/19sp/refcard.pdf CSE 374 AU 20 - KASEY CHAMPION 12
Useful GDB Commands
▪bt – stack backtrace If we get a segmentation fault:
gdb ./myprogram
▪up, down – change current stack frame 1.
2. Type "run" into GDB
▪list – display source code (list n, list <function
name>) 3. When you get a segfault, type "backtrace"
or "bt"
▪print expression – evaluate and print expression 4. Look at the line numbers from the
▪display expression backtrace, starting from the top
-re-evaluate and print expression every time execution
pauses
-undisplay – remove an expression from the recurring list

▪info locals – print all locals (but not parameters)

▪x (examine) – look at blocks of memory in
various formats

CSE 374 AU 20 - KASEY CHAMPION 13

Breakpoints
temporarily stop program running at ▪break – sets breakpoint
given points - break <function name> | <line number> | <file>:<line number>
-look at values in variables ▪info break – print table of currently set breakpoints
-test conditions
-break function (or line-number)
▪clear – remove breakpoints
-conditional breakpoints ▪disable/enable temporarily turn breakpoints off/on
- to skip a bunch of iterations
- to do assertion checking
▪continue – resume execution to next breakpoint or
end of program
▪step - execute next source line
▪next – execute next source line, but treat function
calls as a single statement and don’t “step in”
▪finish – execute to the conclusion of the current
function
- how to recover if you meant “next” instead of “step”

CSE 374 AU 20 - KASEY CHAMPION 14

gdb demo
CSE 374 AU 20 - KASEY CHAMPION 15
 Output is an empty C string, zero
reverse.c characters followed by a null
terminator

CSE 374 AU 20 - KASEY CHAMPION 16

 Testing
Computers don’t make mistakes- people do!
“I’m almost done, I just need to make sure it works”
– Naive 14Xers

▪Software Test: a separate piece of code that exercises the code you are assessing by providing
input to your code and finishes with an assertion of what the result should be.

1. Isolate
2. Break your code into small modules
3. Build in increments
4. Make a plan from simplest to most complex cases
5. Test as you go
6. As your code grows, so should your tests

CSE 373 SP 18 - KASEY CHAMPION

17
Types of Tests
▪Black Box
-Behavior only – ADT requirements
-From an outside point of view
-Does your code uphold its contracts with its users?
-Performance/efficiency

▪White Box
-Includes an understanding of the implementation
-Written by the author as they develop their code
-Break apart requirements into smaller steps
-“unit tests” break implementation into single assertions

CSE 373 SP 18 - KASEY CHAMPION

18
What to test?
Expected behavior
-The main use case scenario
-Does your code do what it should given friendly conditions?

Forbidden Input
-What are all the ways the user can mess up?

Empty/Null
-Protect yourself!
-How do things get started?

Boundary/Edge Cases
-First
-last

Scale
-Is there a difference between 10, 100, 1000, 10000 items?

CSE 373 SP 18 - KASEY CHAMPION

19
Tips for testing
▪You cannot test every possible input, parameter value, etc.
-Think of a limited set of tests likely to expose bugs.

▪Think about boundary cases

-Positive; zero; negative numbers
-Right at the edge of an array or collection's size

▪Think about empty cases and error cases

-0, -1, null; an empty list or array

▪test behavior in combination

-Maybe add usually works, but fails after you call remove
-Make multiple calls; maybe size fails the second time only
Appendix

CSE 374 AU 20 - KASEY CHAMPION 21