CS240 Lab 6

GDB and Pointer Manipulation

Objective

This lab is an exercise on writing robust program and using GDB to debug programs. At the end of this lab, you will be familiar with the core dump file and how to fix the Segmentation Fault problem.

Preparation

Download the following files, you will need them in the lab.

lab6.c - This file contains code to evaluate postfix expression. The code is similar to what you implemented in Project 1.

stack.c - This file contains implementation of a stack. This implementation of stack takes the pointer to an array stack, the stack pointer top, and the size of the array size as arguments. This allow the same code to operate on different stacks instead of implementing the stack operations for different stacks. For example, you have two stacks given by (stack1, top1, size1) and (stack2, top2, size2). To push an item onto the first stack, you call stack_push(stack1, &top1, size1, [item to push]). This way, you do not need to write two push functions for two different stack.

stack.h - This file contains the prototypes of stack operations that can be used in the program. Take a look at how #define is used to prevent including the file multiple times as discussed in lecture.

Makefile - This is the make file. Take a look at this file. The program is compiled with -g -O0 in addition to what you usually have. -g tells the compiler to emit verbose debugging information into the executable, and -O0 tells the compiler to not perform any kind of optimization to the program. Optimized programs are harder to debug.

Now, compile the program with make and run the program. Suprisingly, the program crashes!

lore 14 % ./lab6.out
Enter an expression in postfix order. E.g. 1 234 5 * 6 / + 7 - 89 -
1 234 5 * 6 / + 7 - 89 -
Read a number '1'
Segmentation fault (core dumped)
lore 15 %

Lab Exercise

There are three parts to this lab.

• Fix the errors in the program.

  When you get a segmentation fault, that means your program is accessing some memory location that the program is not supposed to access. This type of error is usually hard to debug. Now do the following:

  1. Run your program with GDB by typing gdb lab6.out on the shell.
  2. Now you see (gdb), type run to start your program.
     
     

     (gdb) run
     Starting program: lab6.out
     warning: Temporarily disabling breakpoints for unloaded shared library "/usr/lib/ld.so.1"
     Enter an expression in postfix order. E.g. 1 234 5 * 6 / + 7 - 89 -
     

  3. Now the program is running and waiting for input. Type a postfix expression, for example, 1 234 5 * 6 / + 7 - 89 -.
  4. Now the program crashed, but GDB tells you the line where the program crashes--line 10 of stack.c.
     
     

     Program received signal SIGSEGV, Segmentation fault.
     0x00010eb4 in stack_push (stack=0x21420, top=0x21418, size=4, item=1)
     at stack.c:10
     10 *(stack + (int)top++) = item;
     

  5. At this point, you're back at (gdb). You can investigate the value of variables by printing them (e.g. (gdb) print stack).

     Fix this line of code so that it works correctly.

  6. Repeat the process until all errors are fixed. There are at least 4 errors in stack.c.
  
  
• Completes the TODOs in stack.c.

  Take a look at the content of stack.c. These are examples of poor implementation. For instance, the stack_push() function does not check whether the stack has full before pushing a new item onto the stack. This potentially causes error in a program.

  Validates the input arguments before performing the operations by completing the TODOs. When the input is invalid, print out an error message and return.

  Doing this in your future projects and labs will make your programs more robust and reduce the amount of time you spend on debugging.

• Investigate on buffer overrun.

  There is another problem in the program that you may not have discovered earlier. The program crashes when encounter a very long number, e.g. 123.45678987654321 987.65432123456789 +.

  Program received signal SIGSEGV, Segmentation fault.
  0x00010870 in getch () at lab6.c:32
  32 return (bufp > 0) ? *(buf + --bufp) : getchar();

  The logic of that line of code is actually correct but the program crashes. So, we will trace this backward to find out the source of the problem. Type backtrace or bt in GDB.

  (gdb) backtrace
  #0 0x00010870 in getch () at lab6.c:32
  #1 0x00010a88 in getToken (s=0x212c8 "123.456789875ÿÿÿ") at lab6.c:57
  #2 0x00010b44 in main () at lab6.c:78
  (gdb)

  The backtrace command shows the program flows. The program starts from main(), calls getToken() on line 78, and calls getch() on line 57. GDB also prints out the function arguments. Take a look at the function argument of getToken(), instead of the actual number you entered, the last few characters have been replaced with some garbage ÿÿÿ. That is usually an indication of buffer overrun.

  Fix the buffer overrun problem in getToken() function. The function should check whether the index i will go out of bound in array s before appending the character. If the index is going out of bound, print out an warning message and return without appending the character.

Turnin

When you are satisfied that your program works correctly (or you run out of time), please do the following.

1. Create a directory named lab06
2. Copy all program files (*.c and *.h) and your Makefile to the directory created in step 1.

3. Goto the parent directory of lab06 and type the following command into the terminal:

   turnin -c cs240=XXXX -p lab06 lab06

   where XXXX represents your lab section number.

   The turnin section is as follows:

   Section	Time	TA
   0201	Thursday 15:30-17:20	Dan Zhang
   0301	Friday 09:30-11:20	Suli Xi
   0401	Friday 13:30-15:20	Youhan Fang
   0501	Thursday 09:30-11:20	J. C. Chin

   Make sure turnin reports that your project was submitted for grading. You can check the files you have submitted by running the following command:

   turnin -c cs240=XXXX -v -p lab06

4. Submit often to make sure that you did not try to submit after turnin has been turned off.

Grading Breakdown

Additional Information about GDB

GDB is a powerful interactive debugger for many compiled languages. We will of course be focusing on C.

GDB can be used in one of two major fashions -- at runtime (gdb is started before there is a problem) or post-mortem (gdb is run to determine why a program that has already died did so). Runtime debugging is desirable whenever possible, but post-mortem debugging is useful when you have a process that fails in some unexpected way and leaves a core dump.

These two major modes of operation are invoked in different fashions. To debug a program at run time, you can either start the program from within gdb or attach to an already running program. To start a program within gdb, you would do the following:

%gdb [progname]
(gdb) run

The second common form of runtime debugging is attaching GDB to a process that is already running. This requires you to know the PID of the running process you are interested in:

%gdb [progname] [PID]

After connecting in this fashion the program can be debugged normally, as if you had started gdb and run the program from there.

To invoke gdb for post-mortem debugging, you must have both the binary you wish to debug and the coredump file from where it failed. (FYI, you can often force a core dump with Ctrl-\ [control backslash]. However, it is often more useful to attach gdb to the running process than force a core.)

%gdb [progname] [coredump file]

Coredump files can also be loaded at runtime in GDB with the core-file command, and executables can be loaded with the exec-file command.

Here is a brief list of GDB commands you will find useful.

Remember that the source code line printed to the screen when the program stops is the em>next line to be executed, it has not yet run.