LS Tools for FORTRAN Debugging

The easy way to avoid those bugs that make you feel foolish.

By Jörg Langowski, MacTech Magazine Regular Contributing Author

Whoever has written a more or less complicated program (and you probably wouldn’t be reading this if you hadn’t) knows that the hardest bug to find is always the next-to last (you won’t find the last one, of course). I’m using Fortran for most of my programming (and even dare to admit that): it is nice to be able to use math libraries and other existing code and put that directly on the Macintosh. But whenever I sit for days over a piece of code and just don’t see why it won’t work, only to find out that I had mixed up the order of parameters or their types in some obscure subroutine call, I start hating programming in general and Fortran in particular. In C++ types are checked: if you try to pass an integer for a real, the compiler will complain. If I only had the time to recode all my stuff into C++, I’d probably do so.

But at the moment, I’m working a lot with Fortran, like many of my colleagues. So we’d better have some good debugging aids that save us time. Language Systems has just presented a series of such tools, which I’d like to tell you about.

FLint

A typical error in languages which don’t have type checking is to pass a parameter of a wrong type to a subroutine. Look at the following example:

 program calls
 
 real*8 x
 real*8 b(50,50)
 integer n
 character*40 c
 
 call sub_a (x, b, n, c)
 write (*,*) ((b(i,j),i=1,5),j=10,15)
 
 call sub_a (b, n, x, c)
 write (*,*) ((b(i,j),i=1,5),j=10,15)
 
 end
 
 subroutine sub_a(x, b, n, c)
 
 real*8 x
 real*4 b(50,50)
 integer n

 character*40 c

 do i=1,50
 do j=1,50
 b(i,j) = i + 0.01*j
 end do
 end do
 
 return
 end

where the subroutine sub_a, which writes into the array b, is called twice from a main program. Both calls are wrong: in the first case, an array of the wrong type is passed (real*4 instead of real*8), and on the second call, the order of the parameters is completely mixed up. Of course, the output values, after the calls to sub_a, will be totally wrong.

The example is trivial, and the error in this case would be rather easy to catch. The program even ran on my machine without complaints, even though the subroutine will write half the values for b into no-man’s land, the array passed being only half as big as it should be. However, errors of this kind do happen often enough, and will be much harder to catch in a complex program than in the isolated example given here.

The interesting thing is that the compiler swallows the code without any error or warning messages. It would be nice to have a tool which will indicate if a subroutine has been called with the wrong number or type of arguments.

LSFlint, contained in the debugging toolkit for LS Fortran distributed by Language Systems, does this kind of type checking, and a lot of other things. It runs under the MPW shell; for testing the example above (in file calls.f), you might type

LSFlint calls.f

and you’ll get this output:

      call sub_a (b, n, x, c)
### lsflint - Warning - SUB_A arg   2:N, possible size discrepancy exists
### lsflint - Warning - SUB_A arg   2:N, possible type discrepancy exists
### lsflint - Warning - SUB_A arg   3:X, possible size discrepancy exists
### lsflint - Warning - SUB_A arg   3:X, possible type discrepancy exists
    File "calls.f"; Line 11
#------------------------------------------------------------
    File "calls.f"; Line 8 # earlier usage
#------------------------------------------------------------

      subroutine sub_a(x, b, n, c)
### lsflint - Warning - SUB_A arg   2:B, possible size discrepancy exists
### lsflint - Warning - SUB_A arg   2:B, possible type discrepancy exists
    File "calls.f"; Line 16
#------------------------------------------------------------
    File "calls.f"; Line 8 # earlier usage
#------------------------------------------------------------

Of course, LSFlint includes complete syntax checking, you’ll get the same syntax error messages as the compiler would give you for wrong code. It works at almost the same speed as the compiler: in my test it took 7 minutes for checking a program of a total of 4355 lines of code, while the compiler (at opt=3) took 5:30 minutes. However, in that case it created pages of warning messages (that was on a program that ran correctly!): about variables that had been declared but never used, about possible problems with passing pointers to matrices in subroutine calls, and even about some places where I had called a subroutine with the wrong number of parameters! It is actually amazing that that program gave the correct answers. This will give me now some opportunity to really ‘lint out’ that code, which is what LSFlint is all about.

An obvious area of application for LSFlint is for those who use Macintosh system calls from Fortran. You can easily make a mistake about which parameters have to be passed by value, by reference, and which are 16 or 32 bits long. All those errors will be caught by LSFlint.

Finally, if you are still using common blocks in your code (which I think is an ugly practice, especially since LS Fortran now allows named global variables), the program will detect differences in the size of common blocks and other discrepancies between routines. Also, when structures are passed to subroutines it will not only be checked whether the size and type of the elements matched, but whether the structure actually has the correct name. All in all, a very useful tool for improving Fortran code (one must mention that Lint, a similar utility for C code, has been available on the Unix scene from various sources for a long time). Still, you have to write your own code.

DebugLib

The second tool included in the LS debugging toolkit is DebugLib, a debugging library. By linking your code with DebugLib.o (it contains routines which override some of those in FORTRANLib.o), you will have interactive control over the various debugging options that Language Systems Fortran offers: until now, you would have had to recompile the program for changing those options. Now, when you have compiled a program with -debug=3 -r -ov and linked with the debugging library, a dialog appears when you execute the program that allows you to set the debugging options interactively:

Figure 1

Each time the dialog comes up, it tells you where you are in the program (top two lines), and lets you check the debugging options. The last option is especially useful; it will let the program pause (and redisplay this dialog) on each subroutine entry, when you hold down the caps lock key. Thus, by releasing the caps lock key you may accelerate your program while it is executing uncritical sections of code. There is also an option that tries to recover from stack overflow errors by increasing the stack space; this can be important if you use lots of local variables that take up space on the stack on every subroutine call. The other options should be evident; you know already the trace window from earlier versions of LS Fortran (it displays continuously the line and routine name where the program is executing).

SourceBug

Finally, the debugging toolkit contains a copy of Apple’s SourceBug, an interactive source code debugger that is much easier to use (though less powerful) than the SADE debugger. It needs a symbol file that the compiler and linker create from your application; for LS Fortran, you use the -sym option for the compiler and the -sym on option for the linker. You then open up SourceBug, and use the Open command from its File menu to start up your application. SourceBug will then open the ‘program browser’ which contains a list of all the source files that make up your program and for each source file all its routines.

You can set breakpoints in your program simply by choosing a routine with the two lists on top, and then click next to the program line where you want to have the breakpoint. Of course, SADE would give you much better control, for instance you can have conditional breakpoints; but SourceBug is very straightforward to use and needs no long setting up, like SADE.

Figure 2

You start your application by selecting ‘Run’ from a Control menu. When the program then hits the breakpoint, a second browser will come up, the ‘stack crawl’ window, which shows the routine where the break occurred and the calling sequence starting with the main program:

Figure 3

Here, you may now inspect the values of all variables simply by selecting them with the mouse and selecting ‘Evaluate’. I should say that you may find some difficulties here when you select big arrays to display; it takes forever to refresh the window which displays its values. But for simple variables or smaller arrays, it works just fine.

Other goodies

There has been more information on my desk about new Products that run with Fortran. Two tools, also available through Language Systems for some time now, are a plotting library called SuperPlot and a ‘code structurer’ that converts spaghetti code into nicely stratified lasagna. A review of these two utilities is long overdue, and I’ll try to put it into this column before long. But until then, we should also hear again about C++ and Forth.

MacForth people, please take note that we are desperately looking for good examples written for MacForth - we’d like to cover the only commercial Forth product for the Macintosh a little more than we have usually been doing (which should not be difficult).