Bug 212224 - Unresolvable type causes ArrayOutOfBoundsException in IType.resolveType
Summary: Unresolvable type causes ArrayOutOfBoundsException in IType.resolveType
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.4 M5   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 212225
  Show dependency tree
 
Reported: 2007-12-06 21:33 EST by Cameron Bateman CLA
Modified: 2008-02-05 03:12 EST (History)
3 users (show)

See Also:


Attachments
Reproduces the problem. (5.54 KB, text/plain)
2007-12-06 21:34 EST, Cameron Bateman CLA
no flags Details
Stack traces copied from JUnit test failures. (12.69 KB, text/plain)
2007-12-11 14:24 EST, Cameron Bateman CLA
no flags Details
Configuration dump (334.25 KB, text/plain)
2007-12-12 14:37 EST, Cameron Bateman CLA
no flags Details
Junit project that reproduces the problem (6.35 KB, application/x-zip-compressed)
2007-12-14 15:04 EST, Cameron Bateman CLA
no flags Details
Proposed fix and regression test (2.90 KB, patch)
2007-12-17 09:15 EST, Jerome Lanneluc CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Cameron Bateman CLA 2007-12-06 21:33:04 EST
The attached test case reproduces the case assuming that your target junit-workspace contains a project called "TestProject" that has a JDK defined in its build path.  Note that the test cases that try to resolve a valid type will succeed (testString, testInteger, testBoolean), whereas ones that try non-resolvable types (including the proper name of primitives) will fail due to an exception like the one below.

This problem is new in the 1204 build.  Prior to this build (last in use was 1127) the same test case that discovered the problem worked fine.

Note that the choice of the resolving type affects the failure as the problem seems to occur due to the constructor for AbstractList$ListItr.  This causes a problem with some (somewhat questionable) code in BinaryTypeConverter.convert which assumes that the args and argTypes arrays for the constructor will have the same size.  I assume that the underlying problem is deeper, however it would also seem advisable that an assertion is made on the equal size of these two arrays.

I have marked this as "major" since it will cause us loss of functionality in cases where we need to resolve types in the affected type hierarchies.


java.lang.ArrayIndexOutOfBoundsException
at org.eclipse.jdt.internal.core.BinaryTypeConverter.convert(BinaryTypeConverter.java:158)
at org.eclipse.jdt.internal.core.BinaryTypeConverter.convert(BinaryTypeConverter.java:244)
at org.eclipse.jdt.internal.core.BinaryTypeConverter.convert(BinaryTypeConverter.java:210)
at org.eclipse.jdt.internal.core.BinaryTypeConverter.buildTypeDeclaration(BinaryTypeConverter.java:98)
at org.eclipse.jdt.internal.codeassist.SelectionEngine.selectType(SelectionEngine.java:1135)
at org.eclipse.jdt.internal.core.NamedMember.resolveType(NamedMember.java:292)
at org.eclipse.jdt.internal.core.NamedMember.resolveType(NamedMember.java:245)
at org.eclipse.jst.jsf.common.util.TypeUtil.resolveInParents(TypeUtil.java:368)
at org.eclipse.jst.jsf.common.util.TypeUtil.resolveTypeRelative(TypeUtil.java:293)
at org.eclipse.jst.jsf.common.util.TypeUtil.resolveType(TypeUtil.java:62)
at org.eclipse.jst.jsf.common.util.JDTBeanProperty.getType(JDTBeanProperty.java:115)
at org.eclipse.jst.jsf.common.util.JDTBeanProperty.isEnumType(JDTBeanProperty.java:132)
at org.eclipse.jst.jsf.context.symbol.internal.impl.IJavaTypeDescriptor2Impl.getPropertiesInternal(IJavaTypeDescriptor2Impl.java:595)
at org.eclipse.jst.jsf.context.symbol.internal.impl.IJavaTypeDescriptor2Impl.getBeanProperties(IJavaTypeDescriptor2Impl.java:268)
at org.eclipse.jst.jsf.context.symbol.internal.impl.IBeanInstanceSymbolImpl.getProperties(IBeanInstanceSymbolImpl.java:84)
at org.eclipse.jst.jsf.context.symbol.tests.ModelBaseTestCase.populatePropertyMap(ModelBaseTestCase.java:108)
at org.eclipse.jst.jsf.context.symbol.tests.ModelBaseTestCase.setupBeanProperty(ModelBaseTestCase.java:102)
at org.eclipse.jst.jsf.context.symbol.tests.TestTypeCoercion.setUp(TestTypeCoercion.java:58)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:354)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:206)
at org.eclipse.test.UITestApplication$3.run(UITestApplication.java:195)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:130)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3312)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2985)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2381)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2211)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:468)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
at org.eclipse.test.UITestApplication.runApplication(UITestApplication.java:138)
at org.eclipse.test.UITestApplication.run(UITestApplication.java:60)
at org.eclipse.test.UITestApplication.start(UITestApplication.java:210)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:362)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:175)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:561)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
at org.eclipse.equinox.launcher.Main.main(Main.java:1215)
Comment 1 Cameron Bateman CLA 2007-12-06 21:34:31 EST
Created attachment 84698 [details]
Reproduces the problem.
Comment 2 Jerome Lanneluc CLA 2007-12-07 04:39:47 EST
The attached test case passes for me. All tests are green and the following is in the console:

class String [in String.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
class String [in String.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
class Integer [in Integer.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
class Integer [in Integer.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
class Boolean [in Boolean.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
class Boolean [in Boolean.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
null
null
null

Do you have more details on how to reproduce the problem?
Comment 3 Cameron Bateman CLA 2007-12-07 14:06:54 EST
Ah, sorry, forgot to add that I am using JDK5.

From the debugger, the toString() value for the methodDeclaration variable is "com.sun.jdi.InvocationException occurred invoking method."  Don't know if this is important.

(In reply to comment #2)
> The attached test case passes for me. All tests are green and the following is
> in the console:
> class String [in String.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
> class String [in String.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
> class Integer [in Integer.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
> class Integer [in Integer.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
> class Boolean [in Boolean.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
> class Boolean [in Boolean.class [in java.lang [in D:\jdk6\jre\lib\rt.jar]]]
> null
> null
> null
> Do you have more details on how to reproduce the problem?

Comment 4 Jerome Lanneluc CLA 2007-12-11 04:57:36 EST
The provided test case still passes for me with JDK5. All tests are green and the following is in the console:

class String [in String.class [in java.lang [in D:\jdk1.5.0\jre\lib\rt.jar]]]
class String [in String.class [in java.lang [in D:\jdk1.5.0\jre\lib\rt.jar]]]
class Integer [in Integer.class [in java.lang [in D:\jdk1.5.0\jre\lib\rt.jar]]]
class Integer [in Integer.class [in java.lang [in D:\jdk1.5.0\jre\lib\rt.jar]]]
class Boolean [in Boolean.class [in java.lang [in D:\jdk1.5.0\jre\lib\rt.jar]]]
class Boolean [in Boolean.class [in java.lang [in D:\jdk1.5.0\jre\lib\rt.jar]]]
null
null
null

1. What version of JDK5 are you using?
2. The trace provided in comment 0 is for TestTypeCoercion. Can you please provide the trace for the TempTestCase (provided in comment 1)?
3. The toString() value for the methodDeclaration variable being "com.sun.jdi.InvocationException occurred invoking method." just means that there is an Exception in the toString(). This can be ignored.

Comment 5 Cameron Bateman CLA 2007-12-11 14:23:26 EST
(In reply to comment #4)
> 1. What version of JDK5 are you using?

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

This is on Windows XP, although the original failure happened on the WTP build server which is Linux.  I just upgraded to build 1.5.0_14-b03 and the same problem occurs.

> 2. The trace provided in comment 0 is for TestTypeCoercion. Can you please
> provide the trace for the TempTestCase (provided in comment 1)?

Please see attachment.
Comment 6 Cameron Bateman CLA 2007-12-11 14:24:10 EST
Created attachment 84998 [details]
Stack traces copied from JUnit test failures.
Comment 7 Jerome Lanneluc CLA 2007-12-12 10:36:03 EST
(In reply to comment #5)
> (In reply to comment #4)
> > 1. What version of JDK5 are you using?
> 
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
> 
Using this same version, tests are still green for me. Are you using a pure Eclipse build or a modified version?
Comment 8 Cameron Bateman CLA 2007-12-12 14:37:08 EST
> Using this same version, tests are still green for me. Are you using a pure
> Eclipse build or a modified version?

I downloaded eclipse-SDK-I20071204-1547-win32.zip based on the dependencies listed on the WTP downloads page: http://download.eclipse.org/webtools/committers/drops/R3.0/I-I20071207063230-20071207063230/

I notice this zip is no longer available (I get a 404).  AFAIK, the platform has not been modified.  I have also attached my configuration on the newest attachment.
Comment 9 Cameron Bateman CLA 2007-12-12 14:37:52 EST
Created attachment 85110 [details]
Configuration dump
Comment 10 Jerome Lanneluc CLA 2007-12-13 09:24:33 EST
It might depend on the setup of the project that contains the JUnit test. Can you please zip the project that contains the JUnit test from comment 1 and attach it to this bug.
Comment 11 Cameron Bateman CLA 2007-12-14 15:04:47 EST
Created attachment 85306 [details]
Junit project that reproduces the problem
Comment 12 Jerome Lanneluc CLA 2007-12-17 09:14:57 EST
Thanks. I was able to reproduce with this JUnit project.
Comment 13 Jerome Lanneluc CLA 2007-12-17 09:15:57 EST
Created attachment 85379 [details]
Proposed fix and regression test
Comment 14 Jerome Lanneluc CLA 2007-12-17 12:37:30 EST
Fix and test released for 3.4M5
Comment 15 Eric Jodet CLA 2008-02-05 03:12:37 EST
Verified for 3.4M5 using build I20080204-0010