forrtl: severe(111)

[Oscar_B_]

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.

[Mark_Lewy]

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_]

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]

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_]

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]

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]

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?