Fortran subroutine fails on return

Question

I have a Fortran numerical code that calls a subroutine from an external module. This code has been running fine for me until I tried to compile and run on a different machine. On the new machine, my program crashes fairly quickly.

Using debug print statements, I have isolated that the crash occurs on return from the external subroutine. The main program calls the subroutine several times, and the crash occurs on return from the second call to the subroutine (the first call works fine). It always crashes on the second subroutine call with this set of input data, but with another set of input data (roughly 1/3 the size of the first), it crashes on return from the fifth subroutine call.

The symptoms suggest to me that something is getting stored in memory each time and accumulates over each subroutine call until it runs out of space, but I'm not sure what that is or how that would occur. The code is hard to simplify to a minimal working example, but I have posted the relevant portion below. Let me know if there is something else that would be helpful to see. It is basically fixed form Fortran 90.

         use fd

         implicit none

         integer, parameter :: ms = 2000
         integer n
         real(dp), dimension(ms) :: s
         real(dp), dimension(ms) :: e
         real(dp), dimension(ms) :: f
         real(dp), dimension(ms) :: d1f
         real(dp), dimension(ms) :: d2f
         real(dp), dimension(ms) :: c, d
         real(dp), dimension(ms) :: a
         real(dp), dimension(ms) :: b
         real(dp), dimension(ms) :: temp
         integer w
         integer k
         real(dp) th

         do i = 1,n
           temp(i) = a(i)
         end do
         call lprsmf(s(1:n),temp(1:n),n,w,k,th,a(1:n),d1f(1:n),
      *               d2f(1:n))

         do i = 1,n
           temp(i) = b(i)
         end do
         call lprsmf(s(1:n),temp(1:n),n,w,k,th,b(1:n),d1f(1:n),
      *               d2f(1:n))

         do i = 1,n
           temp(i) = c(i)
         end do
         call lprsmf(s(1:n),temp(1:n),n,w,k,th,c(1:n),d1f(1:n),
      *               d2f(1:n))

         do i = 1,n
           temp(i) = d(i)
         end do
         call lprsmf(s(1:n),temp(1:n),n,w,k,th,d(1:n),d1f(1:n),
      *               d2f(1:n))

         do i = 1,n
           temp(i) = e(i)
         end do
         call lprsmf(s(1:n),temp(1:n),n,w,k,th,e(1:n),d1f(1:n),
      *               d2f(1:n))

         do i = 1,n
           temp(i) = f(i)
         end do
         call lprsmf(s(1:n),temp(1:n),n,w,k,th,f(1:n),d1f(1:n),
      *               d2f(1:n))

module fd:

      module fd
        ! Double precision real kind
        integer, parameter :: dp = selected_real_kind(15)

      contains

      subroutine lprsmf(x,y,n,w,k,th,s,d1,d2)
!       INPUTS:
!         x, y, n, w, k, th
!       OUTPUTS:
!         s, d1, d2

        implicit none

        real(dp), dimension(n) :: x,y,s,d1,d2
        integer n,w,k
        real(dp) th

!     ... code here ...

      end subroutine lprsmf

      end module fd

My compiler is gfortran 4.6.1. Besides getting the code to stop crashing, I really would like to understand what is fundamentally going on with the argument passing (as I assume the problem lies with the array slices being passed out of the program). Note that a,b,c,d,e,f,s,temp,d1f,d2f have length 2000, while n, which represents the range of valid data, is in the range 100-500, depending on the input data length.

EDIT: The error message is Windows putting up a dialog informing me that the program has stopped working.

My first thought is to be absolutely certain that the reals you are passing to the routine are indeed double precision, as the routine calls for. More precisely, make sure of what byte size the routine wants to see in its dp arguments (probably 8, but not necessarily) and make sure that is the same as the byte size of the real arguments being passed. Different compilers handle the precision of real numbers differently. — bob.sacamento
OK, if you're sure that all the declarations are 100% consistent, precision isn't the problem. One other thing I can think of is a segmentation fault. Alot of the time, the point of failure will have nothing to do with where the bug in the code actually lies. The two most common causes of seq faults that I have found are writing beyond the bounds of an array and -- not to sound like a broken record -- mismatch between an input parameter list and the types of input variables a subroutine expects. You can track down the former by compiling with array bounds checking. — bob.sacamento
You are "use"ing the module that contains subroutine lprsmf from the program that calls it? Try maximum debugging options with gfortran, such as: -O2 -fimplicit-none -Wall -Wline-truncation -Wcharacter-truncation -Wsurprising -Waliasing -Wimplicit-interface -Wunused-parameter -fwhole-file -fcheck=all -fbacktrace — M. S. B.
Hi, could you update your question with the actual error message you get when the program crashes, is it a segfault? The first thing I would definitely do is follow M.S.B.'s advice, or at least use '-fcheck=bounds' (using gfortran). — steabert
With regards to the do loop, AFAIK they are equivalent. My point concerning the value of n is that you haven't given us a [short, self-contained code example](sscce.org/), which makes it very hard for us to track down what is going on. Can you update your question with a minimal complete program which reproduces your error? — Chris

astay13 astay13 · Accepted Answer · 2012-08-02T18:31:31

Thanks to all for the help in chasing down this problem. I followed M.S.B.'s suggestion and compiled with -O2 -fimplicit-none -Wall -Wline-truncation -Wcharacter-truncation -Wsurprising -Waliasing -Wimplicit-interface -Wunused-parameter -fwhole-file -fcheck=all -fbacktrace. This revealed a memory leak in someone else's older F77 code I had included in my subroutine. Apparently some internal arrays were declared with a length 1 item shorter than needed. I fixed that, and everything seems to work fine now.

Fortran subroutine fails on return

1 Answers