forrtl severe (157): Program Exception - Access Violation on CLOSES

[apfan]

forrtl severe (157): Program Exception - Access Violation on CLOSES

---

I am converting a large system from HP Unix fortran to ifort on the PC. I was able to get the system to come up after adding the assume byterecl compiler option that I learned about here (thanks!). The system does direct io OPENS and CLOSES. It can OPEN files successfully, but every time it tries to CLOSE a file, I get the ACCESS Violation that I listed in the title. Here are my compile options;

-nologo \\
-c \\
-Qzero \\
-Qsave \\
-Qvc8 \\
-Od \\
-Z7 \\
-MD \\
-check:all \\
-warn:all \\
-warn:nodeclarations \\
-extend-source \\
-iface:default \\
-iface:nomixed_str_len_arg \\
-convert:big_endian \\
-assume:byterecl \\
-traceback \\
-fpe:0 \\
-fpscomp:logicals \\
-nopdbfile \\
-debug:full \\
-DUPPERCASE \\
-DWIN \\
-DWIN32X_9

I commented out some closes, and the internal debugger gave back results like
A103C RDM NFC= 44 ISTAT= 1633434201

and

A103C DIRECT_IO NFC= 22 ISTAT= 1280070990

where A103C is the close routine. Here is the text of the key part of that close routine; it had already verified that option was either NULL, KEEP or DELETE.

IF(KOPT.EQ.'NULL')CLOSE(NFC)
IF(KOPT.EQ.'KEEP')CLOSE(NFC,STATUS='KEEP')
IF(KOPT.EQ.'DELE')CLOSE(NFC,STATUS='DELETE')
NUMFIL(NFC) = -1


(where NFC is the file number; i.e., 22 above)

Any suggestions greatly appreciated!

[Steven_L_Intel1]

The usual cause of this is some earlier statement in the program that corrupts data in the run-time library. What I suggest is selectively commenting out earlier parts of the program until you find a piece that, when enabled, causes the error to appear.

[apfan]

Steve, thank you, you do raise an interesting question. I get the impression that Fortran Direct I/O still works on the INTEL PC fortran, based on another thread I saw in another forum. I sincerely hope that is the case, as there are about 340 OPENS, REWINDS and CLOSES in this system. Thus attempting to change it all to 'stream io' as was posited in the other thread would not be a trivial exercise.

So here's the question: This systemdid not corrupt data when it was compiled under, and running on, HP UNIX. I have gotten the impression that the unix fortran compilers are more forgiving of a number of things that PC fortran compilers are not. Is there anything that you recommend I look for that would be a 'known PC fortran quirk' in terms of corrupting things, etc.? Among other things, I think you aresaying, by not saying, that the direct IO itself is not something you think of as a culprit. As this is a very large (640-odd programs, about 109,000 lines of comments and code) haystack to start looking through, anything to focus on would be great! I find that as I go in any directions from the menu of the system, once there is a close involved, this goes south... .

[Steven_L_Intel1]

Of course Fortran direct access I/O works - we wouldn't be a Fortran implementation if it didn't.

If "unix fortran compilers are more forgiving" it's only because they have not kept up in regards to diagnostics. There's nothing inherent in Unix compilers that would make a difference here. (I suppose I should point out also that Intel Fortran has its origins in DEC Fortran for UNIX and VMS systems.) It IS very common for any change in compiler to unmask coding errors that went undetected earlier. This can be as simple as a different layout of variables in memory.

I suggest that you put aside the notion that PC compilers have "quirks" that are causing your problem, and start debugging your application. I know this is not what you want to hear.