ECN No Name Newsletter: May, 1990

The ECN No Name Newsletter is no longer being published. This is an archived issue.

[previous article] [next article]

DBX-The Can-o-Worms brought under control!

Steve Weinrich

For many system users, 80% of their terminal time is spent writing and compiling programs; and most of that 80% is spent debugging. So, what better way to help the user than to shorten that time spent running around on wild goose chases after an elusive bug?

Dbx is a source-level debugger. It can be used for ANY supported language (Pascal, C, Fortran 77, etc) that has been compiled with the -g option. This option tells the compiler to add in special information that allows dbx to trace the program, line by line.

To avoid getting into a lengthy discussion about HOW dbx does its work, why don't I give you some quick examples: Assume that you have written the following program that reads in text from a file until it reads a newline:

/* prog1.c */

#include 
main ()
{
  char *my_array, *temp;
  FILE *fp;
  int c;

  fp = fopen("test.data","r");
  while ((c = getc(fp)) != ' ') {
          *my_array++ = c;
  }
  printf("My_array contains: %s0,temp);
  fclose(fp);
  exit(0);
}

The file "test.data" contains:
blah blah blah test test blah

You compiled prog1.c with:
cc -g -o prog1 prog1.c

And when you execute it, the system responds with:
Segmentation fault (core dumped)

REAL descriptive! Obviously there is something wrong, but WHAT, and WHERE? Note: If you would like more information on what a `Segmentation fault' is, then see the article entitled: "Errors, Errors Everywhere, But Not A Bug To Be Found!" on page 8. First we'll load prog1 (the executable) into dbx by typing: "dbx prog1". Dbx will load your program and return with its command prompt. To give you a quick idea of what dbx can do, look at the following partial list of commands (taken from the manual page) that dbx supports:

This short list will aid us in finding our error. We'll run it first, and see just WHERE the error is happening:

(dbx) run
Running: prog1
signal SEGV (segmentation violation) in main
at line 10 in file "prog1.c"
   10             *my_array++ = c;
(dbx)

At least now we know what line the error occurred on. In some instances, that will be all the help you need, but for this example, we still need to know WHY this happened. It appears that my_array points to something out of bounds. Let's ask dbx to tell us about my_array:

(dbx) print my_array
my_array = (nil)

That tells us that my_array has been incremented too far. But WHEN? To answer that, we will put a stop point at this line, which will stop execution before the line is run:

(dbx) stop at 10
(14) stop at "/home/orchestra/weinrich/prog1.c":10

...then we'll run it:

(dbx) run
Running: prog1
stopped in main at line 10 in file "prog1.c"
   10     *my_array++ = c;

We know that this is the first time we increment my_array, so let's find out where it points right now:

(dbx) print my_array
my_array = (nil)

Ah Ha! It's nil to begin with. The only reason that would be the case is if we ...oops... forgot to malloc space to it. . If we go into the file and add a malloc statement like:

temp = my_array = ((char *) malloc(256));

before the while statement, then I think we will be just fine. After re-loading our NEW version into dbx, we try and run it again:

(dbx) run
Running: prog1
My_array contains: blah blah test test blah

execution completed, exit code is 0
program exited with 0
(dbx) quit

Well. It ran just fine. The error might not have been that difficult to find without dbx, but with this short intro, you can see the potential that dbx has in solving your programming problems.

If you would like to learn more about dbx and what it can do, then read the manual page, type "man dbx" or read Section 11, Programmer's Supplementary Documents (PS1) of the UNIX manual set. Additional questions can be answered by your site specialist.


webmaster@ecn.purdue.edu
Last modified: Thursday, 30-Oct-97 18:12:37 EST

[HTML Check] HTML