ERROR 157: 157 Invalid PAD= specification (see "Input/Output" in the Essential Lahey Fortran 90 Refe

[aguirre_lacoleradedi]

Can anybody explain me what the meaning of this error?

157 Invalid PAD= specification (see "Input/Output" in the Essential Lahey Fortran 90 Reference).

I've been trying to find out, but impossible till now!.

Thanks in advance!

[Steven_L_Intel1]

Um, well, you'd probably want to look in the Lahey Fortran documentation or ask their support or user mailing list, or whatever they have. You aren't using the Intel Fortran compiler.

If you'd post your OPEN statement here, perhaps we could tell you anyway.

[Lorri_M_Intel]

Okay, I'm assuming you got an error 157 running a program built with Visual Fortran, and only had a lahey manual handy.

157 is an access violation, which basically means you're writing into memory you shouldn't be. There are a few common things that cause this:

• passing a constant to a subroutine then trying to modify it in the subroutine/function
• accessing outside of the bounds of an array
• reference to an unallocated pointer

There are, of course, plenty of other reasons why you might get an access violation, these are simply the most common. I believe you'll need to debug your program to see what's causing the problem.

- Lorri

[aguirre_lacoleradedi]

Hello again.

My OPEN statement is: OPEN (21,FILE='xyz.dat',STATUS='OLD')

This file is opened and closed thousands of times during the running process, till it crash.

Inside the subroutine wich opens this file, there is an Allocate sentence, for a bigarray to be dimensioned. (tipically, (1:30000,1:3)

Could this be the problem? i mean, could be the problem to allocate thousands times a very big array? if it's this , how couldit be fixed?

Thanks in advance.

[durisinm]

Opening and closing a file "thousands" of times in a run sounds like a lot. Are you sure that the file is closed every time before you open it again?

I think that allocating a large array many times in your program could be a problem if your computer runs out of memory. Is the array deallocated every time before you reallocate it?

Mike

[aguirre_lacoleradedi]

hi to all...

I though the problem of allocating several times could collapse my system, so i included a sentence DEALLOCATE at the end of the subroutine... but it happens again!

The strangest thing is that, there is no repetitive behaviour in the problem: sometimes, running the same system, the running proccess cracks in different points, others cracks in the same point...

right now, while i'm writing these lines, the program finishes good with a set of (low value) parameters that made it crashed one hour ago!.

By the way, iwas looking for problems told by Lorri_Menard, but i founded nothing of that...

Does it mean it can be due to "run out of memory" problems or"hardware limits"problems?

Thank to everybody again.

[aguirre_lacoleradedi]

Hello. Just one thing, if it can help...

I've making tests, and it looks like the problem relies in the CLOSE sentence. Has itany logicalsense??

Bye.

[Steven_L_Intel1]

It could be that something in your program is corrupting memory. Do you build with array bounds checking turned on?

[aguirre_lacoleradedi]

Hello again.

It looks really good!.

I built it with array-bounds checking option and there was!..

I've running simulations for 3 days and runs good, no cracking.

Thanks a lot!

Anyway, there is a doubt about all of this: the array wich its bounds were violated is exclusively used in the main program, but, the cracking of the running process always happened inside one of the subroutines, when the sentence CLOSE (21) (a data read-only file).

Thank you to all, again.

Bye

[durisinm]

If you want to investigate this issue more, then you might try this. Remove the array bounds checking option. Change the CLOSE (21) statement to CLOSE (21, IOSTAT=IERROR) where IERROR is an integer variable. Rebuild your project in a debug configuration and rerun the program.

If the program really is crashing on the CLOSE statement, then the debugger should stop there, and you should be able to examine the value of IERROR. That value should be an I/O error code, something other than zero, that you can look up in the Visual Fortran Programmer's Manual.

Mike