NaN appearing in array handed over to a subroutine

[Lars_Beuth]

Hi,

I encounter a problem with a large Fortran code.

I changed a statement like VariableA= 0.1 to VariableA = Data(I)%SomeValuein some routine (so only a minor change of the code). Since then at a completely different, unrelatedlocation in the code I observe the following bug some 'time' after the above statement is executed:

An array Co(NNodes, 3) defined and allocated in routine Main3D is handed over in routineMain3D to a routine Stresses(...., Co, .....) with a long list of other parameters.In routineMain3DCo(5496,2)points to address 0x025E8238. Inside routine Stresses the value Co(5496,2) isstored at address 0x026195B0, which contains the value 'NaN' instead of the correct value so that the program crashes at some later point of execution.

The routine Stresses was written with the Fortran 77 standardwith another Fortran IDE. Inside the routine Stresses, its parameters are defined as follows:

Implicit double precision(A-H, O-Z)

Dimension SomeArray(*)
Dimension Co(NNodes,*)
Dimension B(3,*), CC(*), DW(*)

In fact, the array CC is a 2-dimensional array, so it should be defined as CC(24, *). Although it looks wrong to me, being unfamiliar with Fortran 77, I guess that the Fortran 77 standard allows for this (?). At least, this codenever caused problems.

What goes wrong when calling routine Stresses? What happens when this routine is being called with the array Co? Is this array copied?

I am using Intel Fortran 11.0.072 with Visual Studio 2008 on a 64-bit computer with AMD Athlon Duo Core processor and Microsoft XP 64-bit. I compile the code to 32-bit using Debug mode (the options Check for null pointers ... and Check array and string bounds are switched on).

I would greatly appreciate help with this problem as I am quite lost right now with finding the cause of this bug. I cannot connect the change I made to the code with this bug at a completely different location in the code, which never before caused any trouble.

Thank you very much in advance.

With kind regards

Lars Beuth

[jimdempseyatthecove]

Lars,

do this

VariableA= 0.1
! VariableA = Data(I)%SomeValue

And likewise in all other sections of your cod
That is restore it back close to where it was working

See if the program works again, then one by one switch comment

! VariableA= 0.1
VariableA = Data(I)%SomeValue


When you locate the problem, you will have a proximity of what caused the error.
You might check the value contained inData(I)%SomeValue to seeif it is NaN.

Check more at your code where you do

Data(I)%SomeValue= VariableA

Because if I indexes out of range you can be in trouble

Have you tried the optiion for checks for uninitialized variables and subscript out of bounds?

Jim Dempsey

[Lars_Beuth]

Dear Jim,

Thank you very much for your reply. I found the bug.It is simply a variable being initialised to a value of 0.0, which causes NaN values to occur.

Greetings

Lars

[jimdempseyatthecove]

Lars,

As a diagnostic find where you perform

Data(I)%VariableA = nnn

Add

if(I .eq. 1) write(*,*) LOC(Data(I)%VariableA)

Where you see the NaN write the value ofLOC(Data(I)%VariableA)

See if the location changes

If the location changes, then you must determine why
was the array Data deallocated/reallocated
is the location of Data very low (<4000, deallocated)

If the location does not change then if after you write
Data(I)%VariableA with I = 1 or first index

Use the debugger to set a break on data change for the location of Data(I)%VariableA

If this location normally changes many times during the run of the program then

Data(I)%VariableA = nnn
call bugCheck(Data(I)%VariableA )

And in your routine bugCheck test for NaN.

subroutine bugCheck(X)
real :: X
if(isnan(X)) then
write(*,*) "NaN found" ! put break point here
endif
end subroutine bugCheck

If an arbitrary location in the array changes use the bugCheck to get the location
Then run again and just after you write to that location you add the break on memory change of that location.

Jim Dempsey

[Lars_Beuth]

Dear Jim,

I finally found the bug by further tracing back the source of the NaN values. Until now, I missed checking an array containing these NaN values.

Thank you very much indeed for looking into the problem that I encountered, for the hint, how to keep track of the allocation of arrays in the code.

With kind regards

Lars