Silverfrost Forums

Welcome to our forums

Truncated traceback reports

22 Oct 2018 3:07 #22701

While working on a program consisting of 750 K of source code, or about 22,500 lines, I made steady progress weeding out undefined variables, mismatched arguments, etc., for which FTN95 is an admirable tool.

Because of a bug in the 64-bit backend (see https://forums.silverfrost.com/Forum/Topic/3450 ), I was forced to debug using the 32-bit compiler. At one point, I was mystified by the following run time error:

Runtime error from program:s:\math\luksan\sec\tbed\f90\tsecu.exe
Run-time Error
Error: Zero raised to negative or zero power

 DFUN -  in file tsecu.f90 at line 138 [+002a]
 PA1SF3 -  in file pssubs.f90 at line 470 [+014e]
 PSEC -  in file psec.f90 at line 866 [+17f3]
 PSECU -  in file psec.f90 at line 182 [+054e]
 main -  in file tsecu.f90 at line 66 [+02b6]

That line in DFUN, however, simply reads

      Call tagu14 (nf, ka, x, ga, next)

Where is zero ^ anything in that statement?

Running the same program in SDBG shows that the actual crash happens well inside the called subroutine, and the traceback shown in SDBG at that point shows the line number where the traceback started from.

Here is a short test program to illustrate this issue.

program tst
   implicit none
   real :: x(2), ga(2)
!
   x = [0.0, 0.0]
   call tagu14(x, ga)
   print *, ga

end program

Subroutine tagu14 (x, ga)
   implicit none
   real, intent(in)    :: x(2)
   real, intent(out)   :: ga(2)
!
   real :: a, b, c, d, p, q
!
   a = x (2) ** 2
   b = x (1) ** 2
   c = a + 1.0D0
   d = b + 1.0D0
   p = 0.0D0
   If (a > p) p = Log (a)
   q = 0.0D0
   If (b > q) q = Log (b)
   ga (1) = 2.0D0 * x (1) * (c*b**a+p*a**d)
   ga (2) = 2.0D0 * x (2) * (d*a**b+q*b**c)
   return
end subroutine

Compile with /debug, link and run at the command line. The error is displayed thus:

Run-time Error
Error: Zero raised to negative or zero power

 TST -  in file tagu.f90 at line 6 [+0043]

Running in SDBG correctly shows the error as occurring on Line 26.

When this test program is built and run with /64, the 0^0 error is not trapped. Is there a way to enable trapping such errors in 64-bit programs?

Thanks.

22 Oct 2018 5:59 #22702

I don't know off hand. I will make a note and take a look at it as soon as I can.

31 Oct 2018 3:40 #22722

There is some code in clearwin64.dll to trap errors of this kind but it is clearly not working. I have made a note that this needs fixing.

1 Nov 2018 10:24 #22729

This has now been fixed for the next release of clearwin64.dll.

1 Nov 2018 5:14 #22731

Thank you, Paul.

Please login to reply.