---

Objective

• Debugging

---

why do we debug?

debugging tools:

1. GDB

• powerful, not friendly to beginner, and can't modify code
• when compile, use -g option

2. DDD

• a graphical front-end for command-line debuggers such as GDB, DBX...
• easier to use, has graphic interface, takes more memory, also can't modify code
• it does the samething with gdb

GDB Getting Started: Starting and Stopping

• gcc -g myprogram.c
  • Compiles myprogram.c with the debugging option (-g). You still get an a.out, but it contains debugging information that lets you use variables and function names inside GDB, rather than raw memory locations (not fun).
• gdb a.out
  • Opens GDB with file a.out, but does not run the program. You’ll see a prompt (gdb) - all examples are from this prompt.
• run(r)
• r arg1 arg2
• r < file1
  • Three ways to run “a.out”, loaded previously. You can run it directly (r), pass arguments (r arg1 arg2), or feed in a file. You will usually set breakpoints before running.
• help(h)
• h breakpoints
  • List help topics (help) or get help on a specific topic (h breakpoints). GDB is well-documented.
• kill(k) - Stop execution
• quit(q) - Quit GDB

Stepping Through Code

Stepping lets you trace the path of your program, and zero in on the code that is crashing or returning invalid input.

• list(l)
• l 50
• l 1,12
• l myfunction
  • List 10 lines of source code for current line (l), a specific line (l 50), a range, or for a function (l myfunction).
• next
  • Run program until next line, then pause. If the current line is a function, execute the entire function, then pause. Next is good for walking through your code quickly.
• step
  • Run the next instruction, not line. If the current instructions is setting a variable, it is the same as next. If it’s a function, it will jump into the function, execute the first statement, then pause. Step is good for diving into the details of your code.
• finish
  • Finish executing the current function, then pause (also called step out). Useful if you accidentally stepped into a function.

Breakpoints and Watchpoints

Breakpoints are one of the keys to debugging. They pause (break) a program when it reaches a certain location. You can examine and change variables, then resume execution. This is helpful when seeing why certain inputs fail, or testing inputs.

• break(b) 45
• b myfunction
  • Set a breakpoint at line 45, or at myfunction. The program will pause when it reaches the breakpoint.
• watch x
  • Set a watchpoint, which pauses the program when a condition changes (when the value of x changes). Watchpoints are great for certain inputs (myPtr != NULL) without having to break on every function call.
• continue(c)
  • Resume execution after being paused by a breakpoint/watchpoint. The program will continue until it hits the next breakpoint/watchpoint.
• delete(d) N(range)
  • Delete breakpoint N (breakpoints are numbered when created). Without number, it will delete all breakpoints, watchpoints, or catchpoints
• disable/enable N(range)
  • disable/enable breakpoint N (breakpoints are numbered when created).
• info breakpoints(b)/watchpoints
  • list some info about breakpoints/watchpoints.

Setting Variables

Viewing and changing variables at run-time is a huge part of debugging. Try giving functions invalid inputs or running other test cases to find the root of problems. Typically, you will view/set variables when the program is paused.

• print(p) x
  • Print current value of variable x. Being able to use the original variable names is why the (-g) flag is needed; programs compiled regularly have this information removed.
• set x = 3
• set x = y
  • Set x to a set value (3) or to another variable (y)
• call myfunction()
• call myotherfunction(x)
• call strlen(mystring)
  • Call user-defined or system functions. This is extremely useful, but beware calling buggy functions.
• display x
• undisplay x
  • Constantly display value of variable x, which is shown after every step or pause. Useful if you are constantly checking for a certain value. Use undisplay to remove the constant display.

Backtrace and Changing Frames

The stack is a list of the current function calls - it shows you where you are in the program. A frame stores the details of a single function call, such as the arguments.

• backtrace(bt)

  • Backtrace, print the current function stack to show where you are in the current program. If main calls function a(), which calls b(), which calls c(), the backtrace is

    c <= current location
    b
    a
    main
    

• bt full
  • Print values of local variables.
• up(u)
• down(d)
  • Move to the next frame up or down in the function stack. If you are in c, you can move to b or a to examine local variables.
• return
  • Return from current function.

Handling Signals

Signals are messages thrown after certain events, such as a timer or error. GDB may pause when it encounters a signal; you may wish to ignore them instead.

• handle [signalname] [action]
• handle SIGSEGV nostop
• handle SIGSEGV noprint
• handle SIGSEGV ignore
  • Tell GDB to ignore a certain signal (SIGSEGV) when it occurs. There are varying levels of ignoring.

Examples