Foundations of Computer Systems
|Assigned:||Friday, March 5|
|Due Date:||recommended completion by Friday, March 12 (ungraded).|
|Collaboration Policy:||Level 0 (unrestricted collaboration)|
This mini-lab exercise is designed to give you practice methodically debugging C programs and checking for various kinds of memory errors. The most primitive method of debugging (which you have likely used in the past) is print-based debugging: i.e., add some print statements, re-compile and re-run, then repeat as necessary until you track down the bug. While simple, this type of debugging is also cumbersome and inefficient. It is especially unsuited to many types of common C errors that crash the program without providing any useful information on what went wrong (such as a segmentation fault). In this mini-lab, rather than relying on print-based debugging, you will use two more advanced tools:
valgrind (an automated memory checker) and
gdb (a general-purpose debugger), which are described below.
This lab is ungraded, but completing it will familiarize you with tools that will be extremely useful for the current Lab 2 and will be necessary for future labs. Experience with a debugger is also an important skill for programmers in general. Spending some time up-front getting comfortable with debugging tools will be well worth your initial investment.
Valgrind is a memory checking tool that is designed to spot various kinds of common memory errors. Typical examples include:
The basic operation of Valgrind is simple: Valgrind will run a given program and watch its memory operations as it executes, printing out various kinds of extra output if it observes the program doing unsafe things (such as the examples listed above). To execute Valgrind, just run
valgrind and pass the name of the program you wish to execute along with any command-line arguments to be passed. For example, to run
myprog through the tool with command line arguments
foo 1, you could run:
valgrind ./myprog foo 1
This command will execute
myprog within the Valgrind framework and will print any Valgrind output alongside any output that the program itself produces. A program that passes Valgrind without warnings will produce a relatively small (but nonzero) amount of boilerplate Valgrind output, while a program that has many memory errors is likely to produce a long log of Valgrind messages.
While running Valgrind is simple, the primary challenge is interpreting its output to aid in debugging your program. As a general principle, don't try to read and understand every word of Valgrind's output. Instead, look for key words and phrases (such as accessing uninitialized memory, double frees, memory leaks, etc.) that may give some hint as to what's going wrong, and note which lines of code are generating these messages. Line numbers will be indicated as
myfile.c:123, which would indicate that the warning was generated by line 123 of
myfile.c. Looking at the very first Valgrind warning is also generally a good place to start; later warnings are likely to stem from earlier ones and therefore may be less helpful in debugging.
To some extent, making sense of Valgrind's output simply requires practice. Feel free to ask myself or the LAs if you are not sure what to make of a Valgrind message. These messages may not immediately indicate what's wrong with your code (even if you understand what the message is saying), but they will often point you in the right direction. Plus, an absence of Valgrind warnings is a fairly reliable indicator that your program is free of memory problems.
In cases where Valgrind alone is not sufficient to fix problems, your next step should be using a full-blown debugger such as
gdb. The basic feature of a debugger is the ability to freeze a program's execution midway and allow you to print various pieces of information about the program state at that instant. A full debugger is much more powerful than Valgrind alone but is also more complex, as working with the debugger requires learning the basic debugger commands.
As a very simple example of what one could do with a debugger like GDB, consider the following:
You can launch GDB to debug
myprog by running
gdb myprog. You can then interact with the debugger using GDB commands. Proficiency with GDB requires becoming comfortable with the most common commands. To aid you in this pursuit, I have prepared a GDB Reference Sheet, which lists the most important GDB commands along with illustrative examples. Look over this sheet to get a sense of what is possible with GDB (though not all of these commands will be useful or even make sense initially). It's also a good idea to keep a hard copy of this sheet handy while debugging.
The most important commands to start with are those on the left-hand column (especially breakpoints and execution), along with basic
nextcommands. If the current line is a function call, executing
stepwill move you into the function, while
nextwill execute the entire function and move to the next (consecutive) line, essentially moving you over the function. You generally don't want to step into library functions (e.g.,
printf) but may or may not wish to step into your own functions when called. If you accidentally step into a function and want to get back to the previous (caller) function, use the
print a * b), notations (e.g.,
print 0xAB), and pointer operations (e.g.,
print *ptr). More examples are shown in the GDB reference sheet.
breakcommand can be abbreviated simply
b, while the
stepcommand can be abbreviated simply
Finally, if you would like another reference on the basics of using GDB, here is a short GDB tutorial that may be instructive.
Your task is to debug a series of five short C programs using
gdb, without inserting any print statements into the programs! While print-based debugging has its place, for the purposes of this exercise, consider
printf to be banned.
Each of the five numbered programs (#1 through #5, roughly in order of difficulty) has a bug that in most cases will be too subtle to immediately spot just by eyeballing the program. Some of these bugs result in crashes, while others do not crash the program but instead result in incorrect output.
Starting with program #1, track down the source of each bug and fix it. You should not modify the source code of the program at all until you have already identified the bug and are fixing it. A suggested plan of attack for each buggy program is given below:
valgrindis usually a good first step. Examine the Valgrind output and see if it helps you identify the bug.
gdband debug the program using breakpoints and inspection of the program state. This process, of course, is more involved than just running Valgrind.
The first three programs
strings3.c can likely be solved using Valgrind alone. The last two programs
matvec5.c will almost certainly require you to use GDB to locate the bug.
As a reminder, you will likely want to consult the GDB Reference Sheet when working with GDB.
The lab files are available via GitHub in the usual way; the lab acceptance link is available on Blackboard. Make sure you're doing your debugging on
turing, where Valgrind and GDB are already installed. You may be able to install these tools on your local machine, but such a setup is not supported. From within the repository directory, run
make to compile the five programs, then you can execute them individually by running
./strings2, and so forth.
You are welcome to work with classmates on these exercises and collaborate openly. However, remember that the goal is to practice with the debugging tools, not merely to fix the buggy programs. If you are simply told what the bugs are, then you won't have learned anything about how to debug your own programs. As such, if you happen to spot one of the bugs (perhaps without even using any of the tools), don't deprive your classmates of the chance to track it down themselves!
This lab is ungraded and there is nothing to turn in. However, you are encouraged to seek assistance in completing the lab the same as you would for any regular lab.