Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

Interesting bug

JohnNichols
Valued Contributor II
181 Views
!do 190 iC = 1, ModelA%FFTNumber

    ModelA%FFTDaTA = ZERO

--------------------------------------------------------------------------------------------------------------

So in Modela I store the FFTDATA before it is sent to the FFT Routine. 

I used a do loop to set the vector to all zeros, but a while ago I thought I can just use a 

vector assignment as above, but I got it wrong and had

ModelA%FFTDaTA(i) = ZERO

it worked up until last night when the latest stuff came in and the plotting did not work, so I looked and there was random crap in FFTDATA instead of the zeros. 

Took a few minutes to track and fix the error -- but I cannot see why it worked!

 

Any ideas?

John

0 Kudos
5 Replies
JohnNichols
Valued Contributor II
181 Views

Second interesting observation 

When I was looking for the cause of the bug, I noticed in stepping through the code that the creation of arrays occurred in reverse order 

    REAL , allocatable :: XDATA(:)
    REAL , allocatable :: YDATA(:)
    REAL , allocatable :: ZDATA(:)
    REAL , allocatable :: DDATA(:)

any ideas why that would occur? 

dboggs
New Contributor I
181 Views

Is this not a simple manifestation of the general problem of trying to use uninitialized variables?

It's a common problem because in some languages, and in the old days, you could use y = 1 + x and you would get 1, because x would be zero. Today, setting an uninitialized variable is not the default behavior. Indeed, x may often be zero--in fact is usually zero--but you cannot rely on it; it depends on what recently-used software has been doing with memory storage locations in areas that your program is now using.

So I would suspect that your (mis) statement Data(i) = ZERO is not setting the entire array to ZERO, but only the ith element, and all of the other elements are left uninitialized.

 

JohnNichols
Valued Contributor II
181 Views

dboggs wrote:

Is this not a simple manifestation of the general problem of trying to use uninitialized variables?

It's a common problem because in some languages, and in the old days, you could use y = 1 + x and you would get 1, because x would be zero. Today, setting an uninitialized variable is not the default behavior. Indeed, x may often be zero--in fact is usually zero--but you cannot rely on it; it depends on what recently-used software has been doing with memory storage locations in areas that your program is now using.

So I would suspect that your (mis) statement Data(i) = ZERO is not setting the entire array to ZERO, but only the ith element, and all of the other elements are left uninitialized.

 

But why did it work perfectly for a month and then suddenly stop -- I did not change the code -- I know in reality it is just dumb luck -- but dumb luck for a whole month.  

I checked you are correct on the ith value was set to 0.00  - the rest ranged to infinity 

Thanks

 

Andreas_Z_
Novice
181 Views

Since issues like the one mentioned can go unnoticed for some time, I like the "initialize variables to signaling NaN" switch during code debugging. That is, use the /Qinit:snan  /Qinit:arrays  command line switches (in VS via the Project Properties > Fortran > Data  menu). With those switches, you will typically find such mistakes quickly.

Andi

jimdempseyatthecove
Black Belt
181 Views

RE post #1

When you used the DO loop, ModelA%FFTNumber may not necessarily been the same as UBOUND(ModelA%FFTDaTA).
And thus the DO loop and ModelA%FFTDaTA = 0.0 are not necessarily the same thing.

I assume (possibly incorrectly) that ModelA%FFTDaTA was allocated.

Jim Dempsey

Reply