Read about Logical Structures (Chpt 7 and Web notes), finish Homework 4 and start Homework 5 Start looking at the sample Exams.
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.
f77 -g test.fThis 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"
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 100Stop at the first executable statement in subroutine sgesl
stop in sgeslStop at line 100 if the Fortran variable x is less than 0.
stop at 100 if x<0.0Stop 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.0To 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.
Stops at the beginning of the next executable line of Fortrannext
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 3You can remove all breakpoints with:
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 100In 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 50You can also list ranges of lines from your program, using list. To look and lines 100 through 120 just type:
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:
You can usually ask for several variables at once:
print x,y,zSome 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+zThe 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/2dTo print six words in memory as 32 bit real numbers, starting at variable "x", type
&x/6fxldb 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"
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".
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.
Written and Maintained by John Mahaffy : firstname.lastname@example.org