"Traveling" forrtl: severe(408): fort (2): error

[Gaetano_E_]

I am using Intel Fortran Compiler 14.02.2.14.

I am compiling with the following flags " -fpp -O0 -check all -traceback -g -vec-report0 -debug all  -heap-arrays -ftrapuv".

I keep on getting errors of the type: "forrtl: severe (408): fort: (2): Subscript #2 of the array XXXXX has value 1 which is greater than the upper bound of 0" where the array XXXX that seems to be the culprit of the error changes as I try to fix the problem.

In addition to the problem of the traveling error, I cannot figure out what is going wrong for the following reason. It is not uncommon that, all the times I get this error, I perform some operations on the second subscript of the array a few lines before I get the error. For example:

array(1,10) = 1.d0 ! -- ok

! -- some code

array(1,1) = 0.d0 ! -- forrtl: severe (408) etc.etc.

I apologize, but it is impractical to report the full code here, because the code base is large, and the error is "traveling" from place to place.

This behavior smells like memory error, but I think I am turning on all flags that should point me to an error like that. I am looking for some suggestion on how to move from here.

I am sorry about the choppy message, but I am having an hard time figuring out what is going on.

[Steven_L_Intel1]

Turn off -ftrapuv. It's not doing anything useful for you. Try adding "-warn interface" and see if it tells you anything.

[Gaetano_E_]

Thank you for the prompt response Mr Lionel.

-warn interface pointed to an error that seems minor, but I think it is worth to mention here, as it could perhaps suggest you what could be going wrong.

I am going to write up some code to explain the situation.

subroutine solve( var1, derivedTypeVar)

use derivedTypeModule, only: derivedType
use helperModule, only : initializeHelperModule

implicit none

real(kind(1.d0)) :: var1
type(derivedType) :: derivedTypeVar

call initializeHelperModule(derivedTypeVar)

! more code

call processVar(var1, derivedTypeVar)

end subroutine

I have a variable of a derived type that is passed to a subroutine. The helperModule stores in a variable the derivedTypeVar because it must be used by another subroutine whose signature is  fixed by an interface (it's a library, I can't to much about it).

Now, in the helperModule, I called the derivedType variable derivedTypeVar, i.e. with the same variable name as in the calling subroutine. I had exposed only initializeHelperModule in the calling subroutine, therefore I was not expecting conflicts. This is what -warn interface returns:

error #6405: The same named entity from different modules and/or program units cannot be referenced.

I solved this error by adding:

use HelperModule, only: initializeHelperModule, derivedTypeVarm=>derivedTypeVar

but I feel like I should not have needed it.

Nevertheless, with this fix, at runtime I get the same error that I originally posted 

"forrtl: severe (408): fort: (2): Subscript #2 of the array XXXXX has value 1 which is greater than the upper bound of 0"

Again, any suggestion is appreciated.

[Steven_L_Intel1]

The edit you made would not have any bearing on the runtime error.

It does sound like memory corruption. I often find it helpful to run the program with the memory checking feature of Intel Inspector XE. You can download a free 30-day trial from our web site if you want to try that. My guess is that there is stack corruption occurring, such as if you pass an argument to a routine that writes outside the declared bounds.

[Gaetano_E_]

Thank you for the response and thank you for the pointer. 

I will give a shot at using Intel Inspector XE and I will report back if I find what is going wrong.

[Vahid_E_]

Steve Lionel (Intel) wrote:

The edit you made would not have any bearing on the runtime error.

It does sound like memory corruption. I often find it helpful to run the program with the memory checking feature of Intel Inspector XE. You can download a free 30-day trial from our web site if you want to try that. My guess is that there is stack corruption occurring, such as if you pass an argument to a routine that writes outside the declared bounds.

Hi Steve,

I am having the same problem. If the problem is due to stack corruption, should'n it happen for other routines too? I am only having the problem for one of them. And if it is the case after all, what fixes it?

Thanks

[Steven_L_Intel1]

There's no simple answer to this question. There are countless possible causes of stack corruption. In nearly all cases it has been a coding error in the application, but finding it can be daunting. I often spend a lot of time in the debugger trying to track down such issues. I do try to simplify the program and the build environment as much as I can to see what changes cause the problem to shift or go away.

In a case such as this, I would stop in the debugger at the point where the error occurs and look at what data the instructions are looking at to determine if the bounds have been violated. In the case of array bounds errors, the code is comparing the index against a copy of the bounds in memory somewhere, typically established at the start of the routine. (But if it's a deferred-shape array passed in, it will be in the descriptor.) I'd then rerun it, stopping earlier, to see if the contents are correct, then carefully advance through the code to see where the values change. It is almost always during a procedure call, implying that the called procedure is writing outside the argument boundaries.

Stack corruption can be insidious because the corruption and the symptom can be far apart.

[Vahid_E_]

Thank you very much for your complete answer.

[Vahid_E_]

Maybe this could be helpful to you.