CS 50 Software Design and Implementation

Lecture 8

gdb – Debugging buggy code with the GNU debugger

In the this lecture, we will further demonstrate the use of gdb. People write buggy code. Many students just use printf to debug their code – this is a mistake. Why? Because it’s not a smart way to debug, nor can you find difficult bugs using printf. So to need a more powerful tool; that’s gdb. Start using it now.

In this lecture on debugging we draw from “Linux Programming” by Matthew and Stones in terms of the material and coding examples from their chapter on debugging. References and pointers to these books can be found on the course webpage.

Here is a quick reference for the most common and useful gdb commands

BTW, you can skip these notes if you write bug free code ;-)

Goals

We plan to learn the following from today’s lecture:

• The essential gdb commands you need to know
• Debugging the buggy_sort.c code (3 bugs to find and swat)
• Debugging segment faults with backtrace and stack frames
• Setting breakpoints and commands
• Patching code with gdb
• Fixing all the bugs in buggy_sort.c

The essential commands you need to get by

You need to become familiar with a handful of commands; here is the top 10, OK 13:

help – list commands
run – start your program [with arglist if needed]
list – show lines of source
break – set a break point in your code
next – execute next line, stepping over function calls
step – execute next line, stepping into function calls
print – print the contents of variables and data structures
frame – select frame number, point to the stack you are interested in
backtrace – display program stack and control flow
command – execute GDB command-list every time breakpoint n is reached
cont – continue the execution of the code
quit – quit the debugger

Note, we use the next command in the notes below; next will “step over” functions rather than into them (e.g., typically you would not want to step into the fgets() function). If you want to step into one of your own functions in the control flow of your code then use the step command instead of next.

A case study in debugging buggy_sort.c using the gdb debugger

We use the intentionally buggy buggy_sort.c code from “Linux Programming” by Mathew and Stones. We use gdb in a series of debugging moves that includes set breakpoints, commands, and patching running code to verify fixes to three bugs we encounter. This is a simple example that builts on our use of gdb in the course.

We study three classes of bugs: uninitialized variables, boundary/edge condition bugs and incorrect coding. We find the bugs using different techniques, fix and verify the changes.

The original sort code buggy_sort0.c looks harmless at first glance but pesky bugs lurk. Running the compiled buggy_sort0.c shows nothing!

Let’s instrument the the code to print the main data structure before and after sort runs. To do this we add -DDEBUG code to look at data structures before and after the sort is called buggy_sort1.c . Now we can see from the print outs that the sort does not work. This is our first evidence that things are not hunky-dory, an english term for OK.

We use gdb to set a breakpoint at sort and the step through. The first thing we notice is that the sort fuction does not process the list and fall out of the for loop first time through. Taking a look at the for loop statement more closely we see that it relies on a variable “s” which is not initialized. Note, s could have any value if not initialized. Theefore, could do different things on different machines. We fix this bug by initialising s=1 in buggy_sort2.c

We know that bugs happend at boundary conditions and the there is only one main data structure. Bugs lurk at edge cases. We make the arrays much larger and discover a segment fault lurking. We make the change to the main data structure in buggy_sort2.c. We use gdb to find the second bug and fixed it - for (j = 0; j < n - 1; j++) - n changed n-1. We make the changes to buggy_sort3.c

The final bug is more tricky. We run the code again and note that the sort almost works. We set a break point in sort and look at the results each time the break point is set. It is clear that the loop terminates early. We find the fix and instead of recompiling we use patching of the code. Found and patched the second fix for // n–; commented this line out. buggy_sort3.c

The good code (well, working code) is buggy_sort4.c

We are going to compile and run the code and look at the output:

First bug (buggy_sort1.c): Uninitialized variables

We add conditional code to the buggy_sort1.c so it prints out the result of calling sort(). To get the compiler to compile the conditional code we pass the -DEDUG flag in the compiliation line below. Also, notice we compile with the debugger using the “-g” flag, you can use -ggdb to.

Second bug (buggy_sort2.c): Increase array size to see if bugs at boundary/edges

Bugs happen at boundaries. Writing one byte beyond a byte array will not be detected by the runtime system but if we increase the size of the allocation we might highlight bugs.

Reading a byte beyond a byte array in this example lets the code run somewhat operationally normally. Errors occur at boundary conditions - i.e., at the edge of the data structure. So lets increase the size of the data structure such that an illegal access will show up. We change data to a 4K array buffer.

We “define SIZE 4096” in the code below.

Any access beyond this boundary will show up at execution.

We have a segment fault - we have the bug out in the open!

buggy_sort2.c: segment fault, say what!

We use code inspection and instrumentation and gdb to find the bugs.

We have a seg. fault. But where in the code?

backtrace

The backtrace command helps debug fault segments. It provides the path through the code prior to the point when the segment fault occurs.

This is a short program to the backtrace is very short. We have not called many functions. The sort is called with sort (a=0x600ca0, n=5) at buggy_sort2.c:41. If the code had a more complex trace we would be able to dig into the details and find out the control flow of the code which would be use in getting to the errors.

Third Bug (buggy_sort3.c): Superfluous, but troublesome line in the code

OK. Let’s but the fix in above into buggy_sort3.c and run it again. Hopefully, that was the last pesky bug...

The code completes without a seg fault now but it still does not work. The table is not ordered by the sort. But what we notice is that n=3 before it exits and the next breakpoint is not hit. Looking more closely at the code we see that the code does not execute the outer loop n times where n is 5. n is set to 3 along the way which is incorrect. Closer inspection of the code we can see that line 52 that is culprit (i.e., n–;). The input parameter n dictates how many times the inner and outter loop execute but n should not be decremented in this code because variables i and j are used to drive these loops, respectively:

Patching code

We can use patching to change the code without recompilation. This is very cool. It is like hot wiring cars.

Our buggy sort is no longer buggy - now works great!

We put the fix in buggy_sort4.c

Other useful gdb commands are:

step - single step through a piece of code line by line

next - step “over” a routine that you do not want to step into (by using step)

We strongly recommend that you play with these various versions of buggy_sort and go through the notes and reproduce what we did above in a step by step manner; then you can apply these simple techniques in nailing your pesky buys.