- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
Steve (who sometimes resembles Eeyore)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Does anyone else get this error- or is it just confined to bears?
Bear of little brain
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Start a Fortran Command Prompt and type DF/WHAT What does it display?
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
Um, who was running 6.5A and then reinstalled 6.5 but forgot the A?
Yes, Bear of little Brain!
Um, who was running 6.5A and then reinstalled 6.5 but forgot the A?
Yes, Bear of little Brain!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A bit too much hunny, bear? :-)
Steve
Steve
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page