Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #326063 +++ Build Identifier: I20100608-0911 When one thread is adding expressions through IExpressionManager.addExpressions() or addExpression() and there is another thread that is getting expressions through IExpressionManager.getExpressions, I get the following exception Caused by: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at java.util.Vector.copyInto(Unknown Source) at org.eclipse.debug.internal.core.ExpressionManager.getExpressions(ExpressionManager.java:297) Looking at the code of org.eclipse.debug.internal.core.ExpressionManager public IExpression[] getExpressions() { if (fExpressions == null) { return new IExpression[0]; } IExpression[] temp= new IExpression[fExpressions.size()]; fExpressions.copyInto(temp); return temp; } I think the reason of the exception is that, after the array IExpression[] temp is created according to fExpressions.size(), there is another thread modify fExpressions through addExpression() that makes temp array size be smaller then fExpressons size. So, when the code 'fExpressions.copyInto(temp);' is executed, temp is not large enough to store the elements of fExpressions (see the Vector.copyInto documentation). One solution I can think of is to synchronize the code a bit so that these two lines IExpression[] temp= new IExpression[fExpressions.size()]; fExpressions.copyInto(temp); will not be affected by any change of fExpression size. I cannot find any workaround to avoid this exception because the two individual pieces of code that call getExpressions and addExpression are from different language tools in eclipse, so I need to file this bug. Reproducible: Always Steps to Reproduce: 1.Create a thread T1 that is scheduled to addExpression() repeatedly forever. 2. Create another thread T2 that is scheduled to getExpressions() repeatedly forever. 3. Both T1 and T2 are using different timers to add / get expressions such that they are executed in their own pace.
I'll target this clone for 3.6.2 so it does not get lost.
Unfortunately we've let this one slip and didn't commit it for 3.6.2 in time for adequate testing.