1. CSc 352 Debugging Tools Saumya Debray Dept. of Computer Science
The University of Arizona, Tucson

2. Uninitialized pointers
str was never initialized to point to anything

3. Uninitialized pointers
Suppose this was a program of realistic size.
How would we identify the location and reason for the problem?

4. Locating the problem: gdb
load the program into gdb
run the program within gdb
show where execution stopped
show values of variables

5. Memory error diagnosis: valgrind
invoking the tool:
valgrind progName arg1 arg2 …
indicates:
there was a problem;
what happened
where it happened

6. Dangling pointers We looked at this code earlier: runtime stack
main
my_read
read_string
string a c b
buf
str
dangling pointer!

7. Dangling pointers
Minor variation on this code:

8. (on hedgehog.cs.arizona.edu)
Dangling pointers
the code seems to work!!!
(on hedgehog.cs.arizona.edu)

9. (on lectura.cs.arizona.edu)
Dangling pointers
doesn’t work
(on lectura.cs.arizona.edu)

10. What’s going on? runtime stack
main
my_read
read_string
the array padding[ ] “protects” buf[ ] from getting overwritten — so the code seems to work
(on some machines)
strlen a
padding[ ] a c b
buf[ ]

11. More diagnosis

12. Summary
Just because a program produces the expected output doesn’t mean that it’s correct
the observed behavior may be accidental
the observed behavior may be system-dependent
Use valgrind to check whether the execution was free of memory errors
provides information only about one execution
other executions may contain erroneous behaviors
provides some help in identifying where the error occurred.

13. Another example

14. Example 2
out of bounds memory access

15. Example 2 where the invalid memory access occurred,
(incl. stack trace)
where this memory was allocated
(incl. stack trace)

16. off-by-one problem fixed
Example 3
off-by-one problem fixed

17. Example 3

18. gdb: basic functionality
Interactive debugger
allows the user to run a program and interactively examine its execution. Features include:
breakpoints (“run until control reaches here, then prompt user”)
stack backtrace (chain of calls leading to some point in the code)
examination of program variables
Usage:
compile program using
gcc –g …
invoke the program as
gdb prog (then supply arguments inside gdb)

19. Interactive debugging: gdb
expected behavior
buggy behavior

20. gdb: example usage invocation set a breakpoint start execution
in this case: at entry to main()
start execution
specify command-line arguments here
execution reaches breakpoint and returns control to user
examine the program
move to next statement

21. gdb: Looking at the program
“list the program source around the line number specified”

22. gdb
set a breakpoint here

23. gdb execution reaches breakpoint and returns control to user
single-step through the execution

24. continue to next breakpoint
gdb
examine program state
continue to next breakpoint

25. gdb

26. gdb: moving around the runtime stack
where did the Seg Fault occur?
move up the stack (i.e., to the caller) to examine variable values

27. gdb: other features Gdb provides many other debugging features, e.g.:
conditional breakpoints
“break execution at some point in the code and return control to the user if some condition holds”
watchpoints
“break execution and return control to user if a variable is read or written’
change the value of a variable in the program state
See tutorials in the DOCS area of class website

28. gdb: reading commands from a file
input to the program to be debugged
script of commands to gdb
invoking gdb to read commands from script file

29. ddd: a GUI front end for GDB
common operations
program source
gdb interaction