Description
Your task this week is to learn how to debug C programs. Specifically, you will learn how to use a debugger (the Gnu debugger, GDB) to examine a C program and design test cases that expose bugs inside programs. You will then debug the programs we provide and write a report on the debugging process. The objective for this week is for you to gain some experience with debugging programs in C, particularly with GDB. This skill is critical for testing software. Background Testing is an important part of software development. Software needs to be tested to make sure that it works as intended. Bugs may hide in not-well-tested code for years and cause disastrous events. Some of the most costly bugs and their causes are listed below: Ariane 5 Flight 501: https://en.wikipedia.org/wiki/Cluster_(spacecraft)#Launch_failure The Ariane 5 rocket, Flight 501, launched on Tuesday, 4 June 1996, ended in failure due to an error in the software design caused by assertions having been turned off, which in turn caused inadequate protection from integer overflow. In essence, the software had tried to cram a 64-bit number into a 16-bit space. The resulting overflow conditions crashed both the primary and backup computers (which were both running the exact same software). The Ariane 5 cost nearly $8 billion to develop, and was carrying a $500 million satellite payload when it exploded. Morris worm: https://en.wikipedia.org/wiki/Morris_worm The first internet worm (the so-called Morris Worm), developed by a Cornell University student for what he said was supposed to be a harmless experiment, infected between 2,000 and 6,000 computers in less than a day by taking advantage of a buffer overflow. The specific code is a function in the standard input/output library routine called gets() designed to get a line of text over the network. Unfortunately, gets() has no provision to limit its input, and an overly large input allows the worm to take over any machine to which it can connect. The graduate student, Robert Tappan Morris, was convicted of a criminal hacking offense and fined $10,000. Costs for cleaning up the mess may have gone as high as $100 Million. Ping of death: https://en.wikipedia.org/wiki/Ping_of_death A lack of sanity checks and error handling in the IP fragmentation reassembly code makes it possible to crash a wide variety of operating systems by sending a malformed “ping” packet from anywhere on the internet. Most obviously affected are computers running Windows, which lock up and display the so-called “blue screen of death” when they receive these packets. GDB Tutorial To use GDB effectively, you need to enable the built-in debugging support for the compiled executable. To do so, include the –g option when compiling, as with the factorial code in this week’s SVN directory: gcc –g –Wall factorial.c –o factorial You can start GDB by typing: gdb You can load the executable to debug by using the file command (the first part, “(gdb)”, is the GDB prompt: (gdb) file factorial Alternatively, you can pass the executable name as command-line argument when starting: gdb factorial GDB has an interactive shell, much like the one you use when you log into the Linux machines. It can recall history with the arrow keys, auto-complete words (most of the time) with the TAB key, and has other nice features. If you’re ever confused about a command or just want more information, use the “help” command, with or without an argument: (gdb) help [command] To run the program, type: (gdb) run Or, if the program needs command line arguments: (gdb) run [arg1] [arg2] … This command runs the program. If the program has no serious problems, the program should run fine under GDB, too. If the program crashes, GDB can usually tell you some useful information, such as the line number at which the program crashed and parameters to the function that caused the error. However you don’t need to use GDB to run the program when the program is working. When the program isn’t working, you probably want to pause execution and check the current status of program. To pause the program, you can use breakpoints. Breakpoints can be used to stop the program run in the middle, at a designated point. The simplest way is the command “break”. This sets a breakpoint at a specified file-line pair: (gdb) break factorial.c:18 This sets a breakpoint at line 18 of file factorial.c. You can set multiple breakpoints. The execution stops whenever it reaches any breakpoint. You can look at your source code using the “list” command in GDB. You can list functions by name, for example: (gdb) list factorial If you just type “list” after starting GDB, the debugger will show you the start of main. “List” without arguments moves further along in the file. GDB remembers the last file that you examined, so if you see a line in the code you’re looking at, you can omit the file name when setting a breakpoint. Back to breakpoints. You can also tell GDB to stop when execution reaches a particular function: (gdb) break factorial The execution stops whenever the factorial function is called. You can also stop execution only when a particular requirement (or a set of requirements) is satisfied. Using conditional breakpoints allows us to accomplish this goal. Conditional breakpoints are identical to regular breakpoints, except that you get to specify some criterion that must be met for the breakpoint to trigger: (gdb) break factorial if n == 2 You can add a condition to an existing breakpoint using cond. Each breakpoint has a number, which GDB prints when you create the breakpoint. Let’s say that the breakpoint in function factorial was #2. In that case, the above command is equivalent to: (gdb) cond 2 n == 2 You can also change the condition on a breakpoint, or disable or enable each breakpoint after hitting it. You can also tell GDB to skip the first N times a breakpoint is hit. Use “help” to learn more—these variants are not used as frequently as basic breakpoints. To resume execution, you can use the “continue” command: (gdb) continue The execution will continue until the next breakpoint, unless a fatal error occurs before reaching that point. You can also single-step (execute just the next line of code) with the “step” command: (gdb) step Similar to “step,” the “next” command executes the next line, but does not enter the source of any functions. Instead, “next” silently finishes execution of any called instructions, treating the whole line one instruction. (gdb) next You may need to repeat the “continue,” “step.” or “next” commands multiple times. In GDB, you repeat the last command by just pressing ENTER. When executing through loops, you may want to continue execution until the loop terminates. To do so, use the “until” command: (gdb) until Similarly, you may want to continue execution until the current function returns: (gdb) finish So far, you’ve learned how to interrupt program flow at fixed, specified points, and how to continue stepping line-by-line. When the execution pauses, you may want to see values of variables or even modify variables’ values. You can do so with the “print” and “set” commands: (gdb) print n (gdb) set n = 2 The “set” command sometimes requires you to specify that you want to change a variable: “set var n = 2”. You can call functions in your program as part of a “print” command. GDB uses the stack provided by the hardware and executes the called function in your program. Be careful: those functions can also crash if they are given bad values. If you just want to call a function rather than printing or calculating something based on its return value, use the “call” command instead. Sometimes, it’s useful to add functions to your program solely for use from within GDB. If you want to print an expression or a variable’s value every time GDB stops execution, use the “display” command instead. This command fails when variables in the expression go out of scope, and may change meaning if variables with the same names come into scope (remember that the program has a current point of execution that defines which variables are in scope—that is, usable by name). You can use the “backtrace” command to view a trace of the function calls that brought execution to the current point (the current function, the function that called it, and so forth, all the way back to main). The “backtrace” command (also known as “where”) is particularly useful when debugging with seg faults (illegal memory accesses, as sometimes arise from array bounds errors). (gdb) backtrace You can also use the “up” and “down” commands to change the current scope to the caller/callee function. You can specify how many levels you want to change with these two commands: (gdb) up 2 (gdb) down 1 Other useful commands include “info,” “delete,” and “clear.” You can use the “info” command to list the current breakpoints (“info breakpoints”), local variables (“info locals”), file scope/global variables (“info variables”) register values (“info registers”), and so forth. You can use the “delete” command to delete a breakpoint (or disable it temporarily with the “disable” command, then re-enable it later with the “enable” command). (gdb) delete breakpoint 2 You can use the “clear” command to delete all breakpoints set inside a function. (gdb) clear factorial The Task You need to identify bugs within several buggy programs by using GDB. You need to document the GDB commands that you use and the results that GDB produces in the file report.txt. 1. reverse The first program that you are required to debug is the print reverse program. This buggy program is in the printRev folder in your SVN directory. You may look at all of the code for this particular program. Your task is to document what the code does, how it works, and what arguments it takes. After doing so, you must run the code repeatedly and identify at least three inputs for which the program does not work. You must then fix the bug and document how you fixed it. You must document everything in report.txt. To get started, you can make the program (type “make”), and then run it in GDB by typing gdb prev Then type r This command will run the program with your favorite word as a command-line argument. Use the skills you learned in reading and trying the GDB tutorial (the first part of this document) to debug the program. You may find it useful to write the output of the program into a file using the redirection operator, “>”: ./prev “argument” > out.txt View out.txt to see that the output of the program has been written to that file. 2. primeNumber The next program to debug is the primeNumber program. The correct version of the program can be found on the course website: https://lumetta.web.engr.illinois.edu/220-S18/Ccode/primes.c The buggy program is contained in the primeNumber folder in your SVN directory. The is_prime function has been rewritten in a more efficient way than in the original code. However, the implementation of is_prime function contains a bug. You may not see the source code for the new is_prime function. Your task is to reason about how the is_prime function is implemented and the possible cause of the bug. To help you get started, you can use the following command to generate the executable: make Then start GDB by typing: gdb primeNumber Your task is to use GDB commands to figure out what the possible cause of the bug is inside the is_prime function. Append your findings to the report.txt file that you created in part 1. 3. sort The last program that you are required to debug is the sort program. This buggy program is in the sort folder in your SVN directory. You are given some of the code to look at, but the buggy function is hidden. Your task is to first test this program, then describe the bug in your report. The code implements a Heap Sort on an array of 32 bit integers. A Heap Sort is an in-place sorting algorithm that is generally efficient. To learn about Heap Sort, you may want to read the description of the algorithm at https://en.wikipedia.org/wiki/Heapsort To help you get started, use the following command to generate the executable: make You may then invoke GDB by: gdb sort and run the program by typing “run out.txt” within GDB. Then you should use GDB to analyze the program using runtime information. Because the buggy function is hidden, you should use GDB to monitor the program when it calls into the functions that are visible to you (those in sort.c). In the report, document the GDB commands that you use and the erroneous intermediate values that you find. Also, explain the possible cause of the bug. Pieces There are three buggy programs for this MP: printRev, primeNumber, and sort. printRev: All source code for printRev is provided to you. You may play with the code, however we will only grade the report.txt. Changes to the source code will not count toward your grade. prmain.c: The main file for printRev. pr_buggy.c: This file contains the print_reverse function. primeNumber: The buggy function is_prime is hidden from you. You may play with the source code provided, but we will only grade report.txt. Changes to the source code will not count toward your grade. isPrime.h: This file contains the function definition for the is_prime function. primeNumber.c: This file contains the main function and the helper function divides_evenly called by the is_prime function. sort: The main function and the buggy function heapSort are both hidden from you. You are provided with the source code for helper functions that are called by the heapSort function. sort.c: This file contains the helper functions. Specifics For this MP, you are required to submit a file named report.txt. For each of the three buggy problems, you must first describe the error that the program produces. The description should at least include test cases, the correct output, and the erroneous output. After analyzing the program using test cases, you should analyze the program using GDB. In report.txt, document the GDB commands you use to analyze the program, and also GDB output that contains important information about the program status. Please note that you should not include all output produced by GDB. Finally, please describe briefly what the bug might be, and in the case of the printRev program, how to fix it. Compiling and Executing the Buggy Programs You may use make to compile the buggy programs. You may use gdb {executable} to use GDB to debug the buggy program. Grading Rubric We will only look at report.txt to grade your MP. Identifying the bug (30%) For each buggy program, you need to report the test cases used to test the program, the desired output, and the actual output of the program. You should report test cases for both correct executions and erroneous executions. Trace the bug (30%) For each buggy program, you need to use GDB to trace erroneous executions of the buggy program. You need to report the GDB commands you used and the results GDB produced. You should also analyze the results GDB produced and the relationship between the results and the erroneous behavior. Analysis of the bug (30%) For each buggy program, you need to report what might be the root cause of the bug. For printRev, you should also explain how to fix the bug. Style (10%) Your report should be formatted such that it is easy to read and follow.
