The Program Turns Ugly, Using dbx

Assignment :

Read about Logical Structures (Chpt 7 and Web notes), finish Homework 4 and start Homework 5 Start looking at the sample Exams.

Dynamic Debuggers

Fixing all of your Fortran errors on any reasonably sized program is less than half of the battle. You are likely to have more subtle conceptual or typographic errors, that permit the program to execute, but result in incorrect answers. This is why you must perform simple independent cross checks of your results whenever possible.

When I was in college I located such program "bugs" by the standard method of staring at the Fortran, and inserting many print statements to make sense of the results. In graduate school, my Ph.D. thesis project required a program to predict the behavior of supernovae (long ago in a galaxy far far away, I was an Astrophysicist). I developed a fully functional program over 2 years. Two years later (1976), as a staff scientist at Los Alamos Scientific Laboratory, I was able to develop a program with twice the complexity in 3 months. Yes, part of the time difference was just experience, but a large part was the availability of a tool called a dynamic debugger.

A dynamic debugger lets you take full control of the execution of any program. You can stop it at any point in its execution, and examine the contents of any variable in the program. If you and the debugger are good enough you can also examine the machine code, and ask for the memory address of any variable. This lets you detect code problems that are overwriting parts of memory where they shouldn't. The debugger that I was using in 1976 was a product called DBCTRL, written by a physicist turned systems programmer named John Norton. It was later superseded at Los Alamos and Livermore by another debugger named DDT. Both had more powerful features than any commercial product that I have seen since (with the possible exception of the Cray debugger)..

I mention the relative quality of these older debuggers only to make a couple general points about software. The fact that a program is sold by a well known company, and/or widely accepted by the public, does not guarantee that is the best product in its class. Government laboratories have spent vastly more time and money developing various programs than any company could. In other instances programs have simply been created by very talented individuals as a labor of love. This combination of government and individual programming has resulted in a huge reservoir of free software. However, don't bother searching the WEB for copies of DBCTRL and DDT. Another key thing to remember about programs is that they often become tightly coupled to a specific operating system. DBCTRL and DDT were written to work on an extinct operating system. When you do look for free programs on the WEB look carefully for operating system dependencies before downloading them.

These notes provide a basic description of a Unix debugger called dbx, capable of debugging Fortran and C programs. Unfortunately, the details of commands for dbx vary substantially from one Unix machine to another. And some systems give their debugger a different name. Spend less time learning specific command names from the material below than learning about general capabilities. When using a different Unix platform, look at the manual pages for command details.
You will also experience in a lab session with a good Xwindows interface to a debugger. The specific program is an IBM product called "xldb". It will show you the source code as you progress through your debugging session, the values of variables, and let you point and click to set breakpoints, control execution, or display variables.

Preparation for use:

Always compile your Fortran with the "-g" option

f77 -g test.f
This adds some information to "a.out" called a "symbol table". This is basically an index relating your chosen variable names to the machine memory locations where their contents are stored. It's a good idea (but not mandatory if you're good enough) to keep the resulting executable file "a.out" in the same directory with "test.f"

Simple run of dbx is:

dbx a.out

To run xldb:

You must be at a workstation, and type the command:

xldb a.out

Breakpoints:

The big advantage of a debugger is that you can tell it to stop running at the beginning of any executable line of Fortran and take a careful look at the value of any variable in the program. The first way to do this is with the stop command. Some general forms are:

stop at (line number) stop in (subroutine) stop at (line number) if (logical test) stop if (logical test)
Examples:

Stop at line 100 in your Fortran file

stop at 100
Stop at the first executable statement in subroutine sgesl

stop in sgesl
Stop at line 100 if the Fortran variable x is less than 0.

stop at 100 if x<0.0
Stop at the next Fortran line where x has a value less than 0.0. Warning: this type of test will slow down running your debug session substantially for large codes.

stop if x<0.0
To stop at a statement using xldb or other Xwindows based debugger click on the statement.

The other way to temporarily set breakpoints is to use the step and next commands.

step

Stops at the beginning of the next executable line of Fortran
next

Like step, but if the next executable line is a call to a subroutine, the code skips everything within that subroutine.

At some point the breakpoints you set may become a nuisance and you would like to get rid of one or more of them. The most universal way to do this is to type status and check the resulting printout for dbx's internal number associated with your breakpoint. You remove it with the command:

delete (number)
Example: Your breakpoint at line 100 is the dbx number 3 breakpoint. Remove it with:

delete 3
You can remove all breakpoints with:

delete all

Some versions of dbx let you remove breakpoints by direct association with the Fortran line number using the clear command:

clear (line number)
Example: Remove the breakpoint at Fortran line 100

clear 100
In xldb you can remove a breakpoint by clicking on a statement flagged by a breakpoint mark.

Getting to breakpoints:

Once you've decided where to stop, you need to execute the program. The first time, or whenever you want to restart from the beginning of the program, you must type "run". After you have stopped at a breakpoint, you continue to the next breakpoint by typing "cont".

Looking at Fortran lines to decide where to go next:

When dealing with dbx, you generally don't know what line number is associated with a given Fortran Command. dbx supports the vi search commands "/" and "?" to search for strings. If you want the line number of the Fortran statement "DO 50 I=1,10", try typing:

/DO 50
You can also list ranges of lines from your program, using list. To look and lines 100 through 120 just type:

list 100,120

Looking at the values of Fortran variables:

The primary command here is print. To see the current value of the Fortran variable x in the current program unit type:

print x

You can usually ask for several variables at once:

print x,y,z
Some versions let you ask for a range of elements in an array. To print elements 1 through 8 of array x type the command:

print x(1..8)
You can usually type the full contents of an array x with "print x". When dealing with arrays, you also need to know that some versions of dbx don't like "(" and " )", insisting on" [" and " ]" for arrays. This is due to the fact that these versions were originally developed for debugging C programs.

You can also print arithmetic combinations of variables:

print x*y+z
The most powerful way to look at the contents of variables uses the "&" command. You should consult man for help on this one. To p Print two words in memory as 32 bit integers, starting at variable "ix". type

&ix/2d
To print six words in memory as 32 bit real numbers, starting at variable "x", type

&x/6f
xldb automatically displays values of variables in a special window, and provides drop-down menus to select the format of the display.

Finding your current location within the code:

At times you forget, or don't know what program unit called the subprogram that you are currently examining. To get a full description of your location in the chain of subprogram calls type "where".

Ending your dbx session: Simply type "quit"

Advanced Topics:

dbx supports aliasing and predefinition of your own commands. See the description of "alias" and the ".dbxinit" file in the dbx manual pages (man dbx). You can also reset variable values (on IBMs see "assign"). For further study, I recommend that you type "man dbx > dbxman" and print out a copy of the file "dbxman". In the Hammond computer lab, this can be done with the command "lpr -Pascii dbxman".

Getting some Practice

I have set up two examples (debug.f and debug1.f) for practice. Each has one code bug in it that produces incorrect results. These are short enough that you may be able to find the bugs just by looking at the code, but try using the debugger to get clues as to what is happening.

Remember to be as systematic as possible, when debugging. Once you locate a number that is bad, trace back through everything that contributed to that number, until you find the root cause of the problem.

Final Note

A debugger is good for more than just fixing broken programs. When you are learning a new programming language, it is often useful to run simple programs in a windows based debugger. You can significantly improve your understanding, by stepping through the instructions in a sample program and watching branches and changes in values of variables.

Back to the Table of Contents / Home

Written and Maintained by John Mahaffy : jhm@psu.edu