Back to CFM home             Brown University



Introduction to debugging


  1. What is a debugger?
  2. A lot of people still use write or printf() statements inside their Fortran or C code respectively to try and figure out where they have a mistake. Debuggers are programs that make this task (which otherwise would continuously involve editing your source code just to to add and remove output statements and of course recompiling) easier. Debuggers enable you to start or stop program execution at will given a particular breakpoint in your code, to examine variables at will, even to call function from within them. They also have powerful aliasing features to make repetitive tasks faster. All in all, it pays in terms of your productivity to learn how to use a debugger.


  3. Debugging flags
  4. On all systems, and for both Fortran and C/C++, if one wishes to produce code that will be useful for debugging one has to use the -g flag for both compiling and linking:
    	% cc -g -c c_program.c
    	% cc -g -o run_prog c_program.o -lm
    
    Code that has been compiled with the -g flag will be slow - so don't use it for production runs. On the Suns, acc/cc (for SunOS/Solaris) will allow -g to be used along with optimization flags, on the SGIs you should look at the man pages for debugging flags that do optimization. No such feature exists for the IBMs and the othe Sun compilers where -g overrides any optimization flags. It is recommended that you compile with -g and no optimization and then test your code on small test problems where run time is not a concern. This will enable you to find the bugs that are due to your code alone - optimization can cause additional problems that will obscure the source of your bugs. Of course if you are having problems with your code working on large datasets after a long time, then you may very well need to compile with both debugging and optimization flags.


  5. Debuggers
  6. You should look at the man pages for the following debuggers for more information on how to use them. The graphical ones are very easy to learn, they usually have graphical help pages of their own; of the rest dbx appears to be the easiest to learn.


  7. lint
  8. Sometimes using incorrect (but acceptable) syntax can cause a bug or make your program non-portable (as all compilers are not equally forgiving). For this reason it is sometimes useful to check the correctness of your C code using lint, eg:
    	% lint -I/usr/local/mpich/include mpi.c 
    
    lint detects features of C program files which are likely to be bugs, non-portable, or wasteful. It also checks type usage more strictly than the compiler. lint issues error and warning messages. Among the things it detects are unreachable statements, loops not entered at the top, automatic variables declared and not used, and logical expressions whose value is constant. lint checks for functions that return values in some places and not in others, functions called with varying numbers or types of arguments, and functions whose values are not used or whose values are used but none returned. For more information look at the man page where this paragraph was taken from.


  9. For more information