Software Archive
Read-only legacy content

Error

Intel_C_Intel
Employee
515 Views
I ran into the following error. First, I thought it was due to hugh array error. I reduced, but it did not resolve the problem. Any comments would be very appreciate it.

Thanks,
bp-

forrtl: severe (161): Program Exception - array bounds exceeded
Image PC Routine Line Source
hrdata.exe 00401C5F Unknown Unknown Unknown
hrdata.exe 00438AC9 Unknown Unknown Unknown
hrdata.exe 0042E294 Unknown Unknown Unknown
KERNEL32.dll 77E87903 Unknown Unknown Unknown

Incrementally linked image--PC correlation disabled.
Press any key to continue
0 Kudos
10 Replies
Steven_L_Intel1
Employee
515 Views
This error means that you have indexed an array beyond its declared bounds. For example:

REAL A(10)

...

DO I=1,11

A(I) = 0.0

END DO

When I reaches 11, you'll get the error, because the array is declared as having only 10 elements.

This is usually a programming error - one not detected by other compilers which don't enable array bounds checking by default, the way Visual Fortran 6.x does in a Debug configuration. Sometimes, the programmer declares an array argument as bound (1), assuming that any index value will be ok. This is incorrect - (*) should be used in such cases.

Steve
0 Kudos
Intel_C_Intel
Employee
515 Views
I had this problem many times, one thing I noticed is if you run the program in Debug mode, it often stops at the variable that has the array bounds exceeded. If you are not in Debug mode go to Build, Set Active Configuration, Debug.

Place a breakpoint somewhere early in the code (shortcut key F9) and then press F5 (Run). The compiler will stop at the breakpoint, then press F5 again (Debug Run). It should give the same error, but the code will be stopped at the variable with a blue arrow in the gray bar to the left.

Hope this helps,
dfh
0 Kudos
Intel_C_Intel
Employee
515 Views
ARRAY OVERFLOW

Here is a cautionary tale: one of my programs has compiled successfully over the past 15 years with a variety of FORTRAN compilers and computers. It compiled successfully with CVF 6.0, 6.1 & 6.1A / Windows 95, NT & 2000, and now with CVF 6.5A / Windows NT & 2000. But with CVF 6.5A / Windows 95, on attempted compilation one file bombs out to the fatal blue screen with the message ?A fatal exception has occurred at 0028:C0002696 in VXD VNM(01) + 00001696. The current application will be terminated.? Not the most helpful of messages to a Bear of little brain.

On investigation, the trouble lay with a subroutine that has not been used for many years, and so had not received much attention. The salient parts of the source code were:

 
SUBROUTINE MENU_MO(OMET,NOMET)     ! OMET is an array. 
 
REAL*8 B(6), OMET(1)             ! Now changed to OMET(*), Steve. 
 
WRITE (SCR_UNIT,610) INT(B(7))  ! MET RECORDS OUT OF SEQUENCE 


In the bad old days, it would have written the value of OMET(1) to screen without turning a hair, but what is interesting is that it is only one particular combination of compiler and operating system (plus computer?), that objected to this at compilation time. But couldn?t the error message have been a little more helpful?

On the general subject of array overflow, the most common cause of this in my types of application is using eg A(N) where N is imported as an argument. If N is not set, it will have the value of 0, and the compiler will not be able to flag up that it is used before being assigned a value, as it would if it were not an argument of the procedure.

Bear of little brain
0 Kudos
Steven_L_Intel1
Employee
515 Views
Bear,

In your case, your program apparently stomped on memory used by a device driver. You must have had array bounds checking turned off, as otherwise it would have complained about the out-of-bounds access.

Steve
0 Kudos
Intel_C_Intel
Employee
515 Views
Steve,

The correct form of address is "Oh Bear of little brain!", which is normally fully justified. However, the compiler option check:bounds was in place as always, and the error is reproducible every time. Odd, innit?

Bear of little brain
0 Kudos
Steven_L_Intel1
Employee
515 Views
I'd have to see an actual example - my guess is that either the option was actually not set or that the code isn't doing what you thought it was.

Steve (who sometimes resembles Eeyore)
0 Kudos
Intel_C_Intel
Employee
515 Views
Steve,

I give below a simple Subroutine that gives exactly the same error message as before, but only with the compiler option /check:bounds. With /check:nobounds it compiles OK. When it comes back from the
fatal blue screen to the developer, it displays: Error spawning df.exe

  
SUBROUTINE CRASH_ON_COMPILE  ! CFV6.5A / Windows 95  
REAL*8 B(2)  
B(3) = 1.D0  
END  


Does anyone else get this error- or is it just confined to bears?

Bear of little brain
0 Kudos
Steven_L_Intel1
Employee
515 Views
Sorry - missed that the error occured on compilation, rather than at run-time. We did have a bug in 6.5 that could cause exactly this symptom, when a program had an out-of-bounds array access that could be detected at compile-time, on Windows 95/98. We fixed it in 6.5A. So far, everyone who has reported this to us says that 6.5A fixed it. If you're really running 6.5A, and not 6.5, I'd be astonished.

Start a Fortran Command Prompt and type DF/WHAT What does it display?

Steve
0 Kudos
Intel_C_Intel
Employee
515 Views
Steve,

Um, who was running 6.5A and then reinstalled 6.5 but forgot the A?

Yes, Bear of little Brain!
0 Kudos
Steven_L_Intel1
Employee
515 Views
A bit too much hunny, bear? :-)

Steve
0 Kudos
Reply