Use GDB

From CS113

For dubugging, code must be compiled with the -g and the -O0 option.

[netid@submit cs113]$ gcc -O0 -g -o hello hello.c

Start GDB by executing gdb progname where programe is the name of your program (e.g. hello)

Some useful GDB commands:

• b <function> – Breakpoint on entering function
• r <args> – Run program with command line arguments
• list – print C code
• n – execute one statement
• s – execute one step (step into function calls)
• c – Continue running program
• p <variable> – print the value of a variable
• bt – Backtrace the stack
• fr <num> – Make stackframe <num> current frame for printing variables
• q – Quit
• help – More GDB help

Here is a sample GDB session for cmd.c from how to Write Your First C Program:

[saikat@submit cs113]$ gcc -g -o cmd cmd.c
[saikat@submit cs113]$ ./cmd foo
Segmentation fault
[saikat@submit cs113]$ gdb ./cmd
...
(gdb) b main
Breakpoint 1 at 0x80483a4: file cmd.c, line 3.
(gdb) r foo
...
Breakpoint 1, main (argc=1209306428, argv=0x4802f4c6) at cmd.c:3
3 int main(int argc, char **argv) {
(gdb) n
main (argc=2, argv=0xbfb646e4) at cmd.c:6
6 n = atoi(argv[1]);
(gdb) p argc
$1 = 2
(gdb) p argv[0]
$2 = 0xbfb65c84 "/home/netid/cs113/cmd"
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x48045eae in strtol l internal () from /lib/libc.so.6
(gdb) bt
#0 0x48045eae in strtol l internal () from /lib/libc.so.6
#1 0x48045c57 in strtol internal () from /lib/libc.so.6
#2 0x48043511 in atoi () from /lib/libc.so.6
#3 0x080483eb in main (argc=2, argv=0xbfb646e4) at cmd.c:7
(gdb) fr 3
#3 0x080483eb in main (argc=2, argv=0xbfb646e4) at cmd.c:7
7 m = atoi(argv[2]);
(gdb) p argv[2]
$3 = 0x0

The gcc command (with -g -O0) compiles the program with debugging enabled and all optimizations turned off. Running the command with foo as the argument crashes the program (Segmentation fault). The command gdb started the debugger with the program passed as the command line argument. b main places a breakepoint at the code>main</code> function -- when the executing of the program enters the main function, the program will pause and the debugger will resume. r foo starts running the program and passes in the command line argument foo. Once the breakpoint placed earlier is reached, the debugger prints some information. n executes the next statement, in this case, it formally enters the function which creates the stack frame and sets up the function arguments. After this step, you can see the values of the arguments printed out by the debugger -- argc is 2 and the actual argument array argv beings at memory location 0x4802f4c6. Next, argc and argv[0] are explicitly printed with the two p commands. c continues running the code. While running, the C code crashes (a segment violation -- like a null pointer exception) is raised inside the function ___strtol_l_internal. Running bt lets you see the call-stack or backtrace that lead to this exception. The backtrace shows four nested function calls -- the inner most (#0) is to ___strtol_l_internal, this was called from __strtol_internal (#1), which was called from the function atoi (#2), which was called from main (#3). fr 3 changes the active debuggin stack-frame to #3 (i.e. that for main int the preceeding backtrace). The debugger prints the line of code that called into atoi that ultimately lead to the exception. In this stack frame, printing argv[2] identifies that it is 0x0 or NULL. This was the root cause of the exception that caused the program to crash.