Index Out of Bounds

A few of our customers have reported an "index out of bounds" error that occurs randomly. If they get the error, they can recreate the steps and the program will work properly. We added what should be unnecessary logic, but these few customers are still getting the error. When they report the error, it is happening in different parts of the code (based on the address).

We are using 9.2.2 ECN-4266 32-bit runtime and compiler.
We compile with the following options:
D:\ACU922\ccbl32 -o D:\CBL800\@ -Cr -Ds -Za -lfo ShaneLFO.txt %1

The reports are coming in from customers running Windows XP 32-bit with SP3 as well as customers running Windows 7 with SP1.

An example from today, was
Index out of bounds, upper bound = 5, index = 21
COBOL error at 0056BC in IVDI3

Here is that section of the source code from the LFO:

005682      move 0 to sub, nfld3
00568C      move spaces to contributor-array
005691      move "None or Unknown" to t-contrib-name(1)

005698      perform 5 times
0056A4         add 1 to sub
0056A8         if sub > 5
0056B1            exit perform
               end-if
0056B4         if books-contributor(sub) not = zeroes
0056CB            move books-contributor(sub) to author-keys
0056E0            add 1 to nfld3
0056E4            if nfld3 > 5
0056ED               exit perform
                  end-if
0056F0            read author-file
                     invalid key
0056FC                  move "None or Unknown" to t-contrib-name(nfld3)
                     not invalid
005718                  move author-name to t-contrib-name(nfld3)
00572D                  move contributor-type to t-contrib-type(nfld3)
                  end-read


IVDI3 Fri Sep 12 15:24:47 2014 ACUCOBOL-GT v9.2.2 ECN-4266 Page: 0234


               end-if
            end-perform.

You can see that there should be no way for "sub" to ever exceed 5, yet somehow it does. We have not been able to recreate this in our office, and as I stated above, the problem cannot be reproduced consistently at the locations where it is occurring.

Any ideas or suggestions?

  • Verified Answer

    Is there another thread modifying sub or nfld3 or something in a called program utilizing the same memory space? 

    Also, I seem to recall removing the -Cr compile option in order to solve an issue that we were having at one time with an application.  We do not have much if any code requiring RM COBOL compatibility any more.  I cannot recall what the issue was at the moment, but I know that the issue arose when we went to 9.0. 

  • We tried compiling the program without the -Cr flag, but the one store we had test it still ran into the error.  We do have a thread in the program.  I'm creating unique variables for each of the perform loops that reference variables with occurs to see if that fixes the problem.  Hopefully, this is the source of the problem.

    Thanks for your suggestions/feedback!