Here is a very simple chunk of code using a jre 1.6 run time environment and running in a 64 bit server Server 2008 R2:
….
cntr = 0;
while (cntr < localheaders.size()) {
String tempText = textstring.toUpperCase();
int pos = 0;
int lastindx = 0;
int lendPos;
int tendPos = 0;
while ((pos > -1) && (tempText.length() > 0)) {
int headerLengthbeforeUpper = localheaders.get(cntr).header.length();
String aHeader = localheaders.get(cntr).header.toUpperCase();
int headerLengthafterUpper = aHeader.length();
pos = tempText.indexOf(aHeader);
// 10_21_2010
if (pos > 0) { // ef 07-10-2011
char c;
try {
c = tempText.charAt(pos - 1);
if (Character.isLetterOrDigit(c))
pos = -1;
} catch (Exception e) {
System.out.println("Value of pos->" + pos);
System.out.println("Length of the string->"
+ tempText.length());
System.out.println("header length before->"+headerLengthbeforeUpper);
System.out.println("header length after->"+headerLengthafterUpper);
e.printStackTrace();
}
}
........
What I am finding is that the statement pos = tempText.toUpperCase().indexOf(aHeader); (about 10 lines down)
is being set intermittently to a value in the string tempText that is greater than the length of the string. This results in a java.lang.StringIndexOutOfBoundsException. The index is always within 100 of the actual length of the string. For example, in a test I ran this evening, the pos varaible was set to 24432 for a string of length 24404. Header length is the same before and after uppercasing to address one of the comments below. Note, if I re-run the code on the same file twice in a row, the error does not occur, the second time.
Some additional information:
- I don’t believe its a threading issue since there is only one thread being used.
- The code runs fine in a 32 bit XP environment.
- Both pos and tempText are locally defined variables.
- When I type java -version, I see the following:
Java version “1.6.0_20”
Jav(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
The test environment is running in a VMware Workstation.
I believe this is an environment issue, give the strangeness of the error and the fact that it only shows up in my 64 bit test environment. I’m trying to figure out the source of the problem. Has anyone, had this kind of error in the past? Is anyone aware of bugs related to this particular java build that might cause this kind of error?
Any ideas on how to trouble shoot this problem?
Thank you,
Elliott
Looks like this bug maybe related to your problem:
https://bugs.java.com/bugdatabase/view_bug?bug_id=6942326