CSE 374, Lecture 11: gdb

The stack

We talked about the layout of memory and the address space in an earlier lecture, but today we talked in more detail about the stack, which is where information about the currently running program/function and its associated variables. So if we have a function main() that calls a function foo() and then foo() calls bar(), our stack might look something like this:

    |        ...         |
    |--------------------|
    |                    |
    | variables and info |
    |     about bar      |
    |                    |
    |--------------------| --
    |                    |   |
    | variables and info |   |- "stack frame"
    |     about foo      |   |     for foo
    |                    |   |
    |--------------------| --
    |                    |
    | variables and info |
    |     about main     |
    |                    |
     --------------------
     "bottom" of the stack

For each function that is called, a new "frame" is pushed onto the stack to store information about the execution of that function. When the function returns, the frame is popped from the stack, resuming execution at the function below it (which called it).

Digging deeper, let's take a look at what exactly is stored in a stack frame:

     --------------------
    |                    |
    |       local        |
    |     variables      |
    |                    |
    |--------------------|
    | prev frame pointer |
    |--------------------|
    |   return address   |
    |--------------------|
    |                    |
    | function arguments |
    |                    |
     --------------------

• "Function arguments" are the variables that are passed to the function as arguments. Remember that these are initialized with COPIES of the variables from the caller.
• The return address is the address of the code that should be executed when the function returns. Remember that in C, both the code and the variables/data are all stored in the same address space.
• The previous frame pointer stores the address where the frame of the calling function is. So if a function foo calls bar, then bar's prev frame pointer will point to the frame of foo.
• Finally, we have local variables, which are added to the stack frame as we declare them.

We learned about the structure of the stack because we need to understand the stack in order to start debugging.

gdb

The goal of today is to learn some basic debugging survival skills. No matter how skilled you get at programming, your programs will inevitably have bugs and crash unexpectedly, so learning how to identify and fix bugs is very important. There are a few techniques that we mentioned for debugging crashes or problems in your code:

• Comment out or delete pieces of your code. For instance, if you think you might be crashing due to a bad printf line, comment out the printf and see if the program still crashes.
• Add print statements at different points in your code. For instance, print the contents of the arguments to the function or the string that you are about to print. Printing is a very useful skill to have; it's not very complicated and can be very useful.
• Use a debugger. A debugger is a tool that can stop a running program and inspect (or modify) the code and variables. We'll be learning to use "gdb" (the "gnu debugger") today.

GDB is part of standard Linux tool chain. It supports several languages, including C, and we'll be using it on the command line as we run our C programs.

An example

I introduced a program called reverse.c, which would prompt the user for input, reverse the input string, and print it back to the user. But it crashes! Let's use GDB to debug the program. See the demo script linked on the course website for a log of the gdb commands we used. However, a summary is as follows.

Also linked in the "Links" section of the course website is a "gdb reference card", a very excellent resource for all things gdb if you ever forget a command.

    gdb reverse                # start gdb with the program reverse

    (gdb) break foo            # sets a breakpoint at the function foo - after you
                               # run the program, gdb will stop when it reaches foo

    (gdb) run                  # runs the program
    (gdb) backtrace            # prints out the functions that are on the stack
    (gdb) bt                   #   (abbreviation for backtrace)

    (gdb) up                   # examine the calling function's frame on the stack
    (gdb) down                 # examine the stack frame at the next lowest address

    (gdb) list                 # print the code that is currently executing
    (gdb) print s              # print the value of the variable s
    (gdb) p s                  #   (abbreviation for print)

    (gdb) info locals          # prints out all the local variables and their values
    (gdb) info args            # prints out all the arguments to the current function
                               # and their values

    (gdb) step                 # if the program is stopped, execute the next line of code
    (gdb) s                    #   (abbreviation for step)

Other key things to note about using gdb:

• You must compile your C programs with the "-g" flag in order to use GDB - this tells the compiler to keep extra information in the compiled program, like variable names, that the compiler would normally get rid of, but that are very important when you are debugging.
• There are many other useful commands! Check out the gdb reference card for more commands.
• Learning when to set breakpoints is an art; practice will make you better.
• GDB is a tool, not an end-all-solution to fix all the problems with your program. It is best used as a tool to accomplish a particular task. For example, if your program is crashing and you want to know "what is the stack trace when I get a segfault?", you can use GDB to get the stack trace. It is good for validating a hypothesis, but it is NOT a general testing approach because it is very manual and kind of tricky to understand and use (more on testing in a future lecture).
• Just because your programd doesn't crash does NOT mean that it is correct! Programs can be incorrect in many different ways and still not crash.

GDB tricks:

• When you run GDB you can quickly figure out the cause of a segfault - was it a stack overflow? array overflow? null pointer dereference?
• Print out values of pointers when you have a segfault - a segfault implies you accessed a pointer to an address that you shouldn't have, so look at pointers to find the issue.
• Similarly, arrays can be a source of issues - print out the contents of arrays.