Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

forrtl: severe(111)

Oscar_B_
Beginner
280 Views

Hello

My application is generating the following error:

forrtl: severe(111): position number is outside of the valid range, unit 11, file (...)

I cannot find any documentation on what this specifically means, and since this is happening in a deployed environment, stack traces e.t.c. are not an option (since symbols have been stripped). 

Are any of you aware as to what this error specifically means? I am assuming that it has to do with the POS= input to write and read commands, but since those are 64-bit integers, I am having trouble with understanding how this could be out of range.

 

Thank you in advance.

0 Kudos
6 Replies
Mark_Lewy
New Contributor III
280 Views

POS < 1, perhaps? 

Note for Intel - 111 is not in the "List of Run-Time Error Messages" in my copy of the compiler documentation (Windows XE 2017 U4).

Oscar_B_
Beginner
280 Views

Thanks for your comment Mark - I couldn't find 111 in my list either, which was very surprising to me.

POS < 1 I guess might be an option, but would then be caused by overflow of the POS integer that I am entering, which seems unlikely to me since it is a 64-bit integer. But of course, it could happen.

Steve_Lionel
Black Belt Retired Employee
280 Views

Is this a FORMATTED or UNFORMATTED file? If FORMATTED, the standard says:

If the file is connected for formatted stream access, the file position specified by POS= shall be equal to either (the beginning of the file) or a value previously returned by a POS= specifier in an INQUIRE statement for the file.

In other words, you can't use POS= to position a formatted file outside the data already written. It could be that your POS= variable is being corrupted by an error elsewhere in the program.

Oscar_B_
Beginner
280 Views

Thank you Steve for your reply - this is an unformatted file, so while I understand your comment I do not believe that it is the reason behind the error I am seeing.

Steve_Lionel
Black Belt Retired Employee
280 Views

Since you had not provided a test case, I had to think of what might cause this in the absence of a compiler/runtime bug. Now that we have eliminated that possibility, it's time to see a test case. You may need to provide the client with a non-stripped application in order to gather further information.

You also haven't told us which compiler version you used and whether the application is linked statically or to the shared objects.

Laura_S_3
Beginner
280 Views

POS < 1 I guess might be an option, but would then be caused by overflow of the POS integer that I am entering, which seems unlikely to me since it is a 64-bit integer. But of course, it could happen.

 A mistake I have made in the past is to have intermediate calculations using 32-bit integers, resulting in overflow before the final calculations producing the 64-bit integer. Is it possible that this is your problem?

Reply