IOSTAT = 29

[e_shahraeeni]

Hi,

I am debugging a fortran code with Intel Visual Fortran Compiler XE 12.0.0.104 and recieve IOSTAT = 29 from the following open command:

OPEN(F_MESH,FILE=FICHIER(1:LENF)//'.io_mesh',STATUS="old",IOSTAT=ier)

The file (ex1.io_mesh) is in the same folder as the executable and there is no problem with the release (I mean when I put ex1.io_mesh in the folder that the executable from release configuration is, it works fine).

Any comment would be highly appreciated.

Ebrahim

[IanH · Accepted solution]

This is from within Visual Studio?

If so check that the Debugging > Working Directory project propertiy for the problematic configuration is set to something reasonable. The default if you don't provide a directory is the same directory as the .vfproj file.

To make it the same directory as where the exectable ends up use $(TargetDir).

[e_shahraeeni]

Thanks IanH, got IOSTAT = 0.

But a few lines later, it says FRSWG.exe (the executable) has triggered a breakpoint. I have attached the console as it stops. do you have any suggestion?



what really puzzles me is that it works fine in release and all these happen for debug!

Ebrahim

[jimdempseyatthecove]

Ebrahim,

Did you read your error message?

>>Subscript #1 of the array POROS has a value of 0 which is less than the lower bound of 1

In Debug build you (apparently) have array bounds checking enabled (as you should)
In Release build you do not.

The situation is: You do not see the error in your program with Release build

This is to say in Release build your code is (likely) still accessing POROS(0[,...])
Which is a programming error. If your code is reading this location it is reading junk data, if it is writing to this location (or write/read) it is (may) overwrite something important.
Only on the odd chance that your code writes first, then reuses the 0'th index .AND. by chance that memory location is unused or not reused subsequent to this time in execution would your program appear to work. Don't program on chance.

Use the Debug build to find the bug in your code.

Jim Dempsey

[e_shahraeeni]

Thanks Jim! Actually I was puzzled before reading the error message how it would be possible that something works as Release and fails as Debug!! Anyway, thank you. now I am going through the whole code (which is not mine, BTW) and find a bunch of similar mistake!

Ebrahim

[jimdempseyatthecove]

Some programmers call the program finished when they get correct results. Array access out of bounds sometimes never exhibit problems and at other times exhibit problems only when the privious support personpasses the code off to programmers named Ebrahim. It is good that you have decided to go through the whole code to look for similar errors. The Debug runtime options will catch many such programming errors but not all. Verify that all your subroutines and functions have IMPLICIT NONE. And if necessary gen/warn interfaces. Although this may seem pointless at first (assuming at first you do not see any errors) you will be glad you did the work as you start catching errors. Even when you catch no errors, the procedure will add confidence that the code does not contain argument usage/passing errors (this will not tell you that the program is functionally correct).

Jim Dempsey