Debugger Ritu Chaturvedi 60 321 1 Objectives Background

Debugger Ritu Chaturvedi 60 -321 1

Objectives Background Basic C issues Tools and Techniques Programs Ritu Chaturvedi 60 -321 2

Debug !! If it ain’t broke, don’t fix it. Ronald Reagan If we can’t fix it, it ain’t broke. Lt. Col. Walter Weir Ritu Chaturvedi 60 -321 3

Noticing and Understanding bugs Before you can debug, you need bugs! How can you tell if your code is buggy? You need testing! Ritu Chaturvedi 60 -321 4

Types of bugs What kinds of bugs are there? Syntax errors ◦ Caught by the compiler Build errors ◦ Makefiles can help Semantic errors ◦ Uninitialized variables, dead code, typing wrong variables, pointer errors Ritu Chaturvedi 60 -321 5

Common C errors result from: Preprocessing ◦ Macro expansion System dependencies Explicit memory management Name space issues ◦ System call availability and definitions ◦ Size and representation of types, use sizeof() ◦ Using unallocated or deallocated memory ◦ Use static keyword, minimize use of globals Ritu Chaturvedi 60 -321 6

Debugging techniques Techniques include (but are not limited to): Compiler features ◦ Warnings (-Wtype) ◦ Optimizations (-Ox) printf() debugging Assertions Code walkthrough Debugging tools Ritu Chaturvedi 60 -321 7

printf() debugging Very common, but there are disadvantages: Output is relatively very slow Ad-hoc code addition and removal stdout is buffered and may be lost Solutions: Use macros to encapsulate debug printf’s Use stderr for debugging output Ritu Chaturvedi 60 -321 8

printf() debugging Use macros to encapsulate debug printf’s #include <stdio. h> #define DEBUG // or use cc –DDEBUG filename. c int main(){ int i, nread; nread = scanf("%d", &i); #ifdef DEBUG printf("Number of integers read = %d n", nread); printf("i=%d n", i); #endif } return 0; Ritu Chaturvedi 60 -321 9

Assertions The verb "assert" has 4 senses literally ◦ 1. assert, maintain -- (state categorically) ◦ 2. affirm, verify, assert, avow, aver, swan, swear -- (to declare or affirm solemnly and formally as true; "Before God I swear I am innocent") ◦ 3. assert, put forward -- (insist on having one's opinions and rights recognized; "Women should assert themselves more!") ◦ 4. insist, assert -- (assert to be true; "The letter asserts a free society") When a programmer writes an assert statement he's saying, 'this condition must be true or we have an error'. Ritu Chaturvedi 60 -321 10

Assertions - Always assert that your code is right ! An assertion is a predicate (i. e. , a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place. When should you assert ? - whenever you can use it to verify the truth of a situation: - this pointer can never be null - this number is never smaller than zero - this number has to be in the range of 10 and 30 Ritu Chaturvedi 60 -321 11

Assertions ◦ ◦ ◦ Header <assert. h> Macro assert() Tests value of an expression If 0 (false) prints error message and calls abort Example: assert( x <= 10 ); ÞIf x is not <= 10, the program will print an error message and abort. Ritu Chaturvedi 60 -321 12

Assertions - Placing assertions in the code increases the robustness of the code by letting the programmer catch the logic errors in the early stages of the development. - Assertions are generally useful for testing the pre- and post-conditions of a function. - A pre-condition specifies what must be true when a function is invoked. i. e. , it is a statement by the programmer that a given function should not be entered unless its pre-condition is guaranteed. If it is entered anyway, the function may behave erratically. In general, pre-conditions depend on global variables and input arguments. - A post-condition specifies what must be true after a function completes successfully. Ritu Chaturvedi 60 -321 13

Assertions #include <stdio. h> #include <assert. h> int check. Eligibility (int age, int salary) { assert (age > 21); //precondition if (salary > 5000) return 1; else return 0; } Ritu Chaturvedi 60 -321 14

Assertions Assertions are for programmers – not users Once software is completed and released to end users, the assertions are disabled so that users do not see unexpected, technical messages To disable assertions, use #define NDEBUG before #include <assert. h> OR cc –DNDEBUG …. Ritu Chaturvedi 60 -321 15

Version control As we saw in Assignment 2, version control is essential for tracking code changes, enabling groups of developers to collaborate, and backing up code. Version control is often integrated with bug tracking software – you need to be able to link bugs to specific code revisions. Ritu Chaturvedi 60 -321 16

Debuggers allow you to monitor other programs as they execute, or to investigate why they crash. Debuggers can: ◦ ◦ ◦ Start programs with specified arguments Halt programs on specified conditions Examine program contents Change values Step through code Ritu Chaturvedi 60 -321 17

Compiling for debugging Normally, an executable file does not contain any references to the original program source code, such as variable names or line-numbers the executable file is simply the sequence of machine code instructions produced by the compiler. This is insufficient for debugging, since there is no easy way to find the cause of an error if the program crashes. Ritu Chaturvedi 60 -321 18

Compiling for debugging GCC provides the -g debug option to store additional debugging information in object files and executables. This debugging information allows errors to be traced back from a specific machine instruction to the corresponding line in the original source file. The debug compilation option works by storing the names and source code linenumbers of functions and variables in a symbol table in the object file or executable. Ritu Chaturvedi 60 -321 19

Compiling for debugging The execution of a program compiled with -g can also be followed in a debugger like DDD. Using a debugger allows the values of variables to be examined while the program is running. Ritu Chaturvedi 60 -321 20

GDB The GNU Debugger is the standard (free) debugger for many Unix systems. Current version is 6. 8 http: //www. gnu. org/software/gdb/ Ritu Chaturvedi 60 -321 21

Using GDB First compile the program (and all modules) with debugging flags on: luna: ~/321>gcc -g debug_me. c -o debug_me Then launch the debugger (from the same directory it was compiled in): luna: ~/321>gdb debug_me //debug_me. c #include <stdio. h> /* print a given string and a number if a predetermined format. */ int main(int argc, char* argv[]) { int i = 0; /* check for command line arguments */ if (argc < 2) void print_string(int num, char* string) { printf("String '%d' - '%s'n", num, string); } } printf("Usage: %s [<string>. . . ]n", argv[0]); for (i=0; i<=argc; i++) print_string(i, argv[i]); printf("Total number of strings: %dn", i); } return 0; Ritu Chaturvedi 60 -321 22

Using GDB – breakpoints Next, run the program in the debugger, supplying the command line arguments: run "hello, world" "goodbye, world" The program will run to completion unless a breakpoint has been set: break debug_me. c: 9 (break on line 9) break main (break on function main) Ritu Chaturvedi 60 -321 23

Using GDB – printing Now you can step through the program: next – execute command stop step – execute command, step into if it is a function, and stop To examine variables, use: print var The variable must be in scope. You can also display the values of expressions, casts, and functions, e. g. : print i*2 print argv[argc] Ritu Chaturvedi 60 -321 24

Some gdb commands Ritu Chaturvedi 60 -321 25

Graphical Tool - DDD – stands for Data Display Debugger DDD is a visual interface to the GDB Debugger Ritu Chaturvedi 60 -321 26

Why DDD Its fast Its intuitive I use just printf statements – why do I need a debugger ? ◦ This is like sewing clothes using a needle and thread instead of a sewing machine Ritu Chaturvedi 60 -321 27

Compiling for debugging luna: ~/321>gcc -g debug_me. c luna: ~/321>ddd a. out & OR luna: ~/321>gcc -g debug_me. c –o debug_me luna: ~/321>ddd debug_me & Ritu Chaturvedi 60 -321 28

Customizing DDD Line numbers: Source Display Line Numbers Docking toolbars: Edit Preferences Ritu Chaturvedi 60 -321 29

Setting Breakpoints If the program has run-time errors e. g. it is stuck in an infinite loop, then we want to set a breakpoint in the while loop ◦ Right-click on the line number of the while loop ◦ Select Set Breakpoint ◦ There should now be a stop-sign at that line Ritu Chaturvedi 60 -321 30

Start the Program At the top of the screen, select “Run” to start your program ◦ This can also be found in the ‘program’ menu ◦ If DDD asks for arguments to your program, just leave it blank The program will halt and prompt you for input in the bottom of the window ◦ Enter a small number: something that should finish in less than a second. It should stop again at the breakpoint. ◦ (The black arrow indicates the next line to be executed) Ritu Chaturvedi 60 -321 31

Next, Hover, and Step Use Next to move through the program one line at a time After each Next you can hold your cursor over each variable to see the value ◦ This is called hovering ◦ This always displays the variable’s value at the current line of execution Note ◦ Step will move down the program, one line at a time. It will also step into function calls if there any. ◦ Next would also move down one line at a time, but would skip function calls. Ritu Chaturvedi 60 -321 32

Fixing the Bug So, what’s going wrong? Leave DDD open Open the code in your favorite editor ◦ Fix the code Recompile the code Run the code (on the command line) If you wanted to run it again in DDD, you would need to reload the code in DDD Ritu Chaturvedi 60 -321 33

Ritu Chaturvedi 60 -321 34

Website (DDD Tutorial) : Two good tutorials on DDD: http: //www. gnu. org/manual/ddd/html_mono/ddd. html http: //heather. cs. ucdavis. edu/~matloff/Debug. pdf Ritu Chaturvedi 60 -321 35

DDD and makefile If you have a makefile with several dependent files in it and you would like to use DDD, you must compile each file in the make file with the –g option and then open the executable in DDD.

Some Debugging Theory You have to use breakpoints strategically Suppose you have 10, 000 lines of code with no output and a segmentation fault. Where do you put your breakpoint? The Binary Search Principle of debugging ◦ You don’t look up a word in the dictionary by starting at the first letter ‘A’ page and turning hundreds of pages until you find your word (especially if your word is zebra). ◦ Like searching the dictionary, put a breakpoint in the middle of your program and look at the values there. Is your bug before or after that point? Ritu Chaturvedi 60 -321 37

Examining core files - In addition to allowing programs to be run under the debugger, an important benefit of the -g option is the ability to examine the cause of a program crash from a "core dump". - When a program exits abnormally (i. e. crashes) the operating system can write out a core file (usually named ‘core’) which contains the in-memory state of the program at the time it crashed. This file is often referred to as a core dump. Ritu Chaturvedi 60 -321 38

Examining core files - Combined with information from the symbol table produced by -g, the core dump can be used to find the line where the program stopped, and the values of its variables at that point. - This is useful both during the development of software and after deployment--it allows problems to be investigated when a program has crashed "in the field". Ritu Chaturvedi 60 -321 39

Examining core files Sample program with an invalid memory access : null. c: int foo (int *p); int main (void) { int *p = 0; /* null pointer */ printf(“%dn”, foo (p)); } int foo (int *p) { int y = *p; return y; } -The program attempts to dereference a null pointer p, which is an invalid operation - In order to be able to find the cause of the crash later, we will need to compile the program with the -g option: $ gcc -Wall -g null. c -Note that a null pointer will only cause a problem at run-time, so the option Wall does not produce any warnings. $. /a. out Segmentation fault (core dumped) Ritu Chaturvedi 60 -321 40

Examining Core Files $ gdb a. out core Core was generated by `. /a. out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /libc. so. 6. . . done. Loaded symbols for /libc. so. 6 Reading symbols from /lib/ld-linux. so. 2. . . done. Loaded symbols for /lib/ld-linux. so. 2 #0 13 0 x 080483 ed in foo (p=0 x 0) at null. c: 13 int y = *p; (gdb) print p $1 = (int *) 0 x 0 Note: This shows that p is a null pointer (0 x 0) of type ‘ int *’, so we know that dereferencing it with the expression *p in this line has caused the crash. Ritu Chaturvedi 60 -321 41

Displaying a backtrace The debugger can also show the function calls and arguments up to the current point of execution--this is called a stack backtrace and is displayed with the command backtrace: (gdb) backtrace #0 0 x 080483 ed in foo (p=0 x 0) at null. c: 13 #1 0 x 080483 d 9 in main () at null. c: 7 In this case, the backtrace shows that the crash occurred at line 13 after the function foo was called from main with an argument of p=0 x 0 at line 7 in ‘null. c’. Ritu Chaturvedi 60 -321 42