- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page