Summary: | Java model corrupt after switching target platform | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dani Megert <daniel_megert> | ||||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | critical | ||||||||
Priority: | P3 | CC: | markus.kell.r, Olivier_Thomann, snjezana.peco | ||||||
Version: | 3.5 | ||||||||
Target Milestone: | 3.5 M7 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Dani Megert
2009-04-03 04:49:03 EDT
Created attachment 130807 [details]
Picture showing havoc
In my opinion this issue happens because, sometimes, JavaProject.getPackageFragmentRoots() and JavaProject.getAllPackageFragmentRoots() don't return the same result. The issue is described on http://dev.eclipse.org/newslists/news.eclipse.tools.jdt/msg23983.html and on https://jira.jboss.org/jira/browse/JBIDE-3414 . I have made a workaround for it in JBoss Tools - see https://jira.jboss.org/jira/browse/JBIDE-3414?focusedCommentId=12448646#action_12448646 I'm able to reproduce the problem one out of 10 times. So this is a concurrency issue. Indeed looking at the code, it appears that classpath changes may be lost if the resource delta triggered by the setClasspathContainer(...) is notified in a different thread. Created attachment 132261 [details]
Proposed fix
There is no regression test since this is a concurrency issue
>There is no regression test since this is a concurrency issue
I'd be happy to verify once the code is in HEAD.
Unfortunately, it seems that this patch introduces a regression in the refactoring tests: java.lang.ArrayIndexOutOfBoundsException: 0 at org.eclipse.jdt.ui.tests.refactoring.ccp.CopyToClipboardActionTest.testEnabled11(CopyToClipboardActionTest.java:523) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.UITestApplication$1.run(UITestApplication.java:114) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2393) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2357) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2209) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:499) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:492) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.pde.internal.junit.runtime.UITestApplication.start(UITestApplication.java:46) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1287) at org.eclipse.equinox.launcher.Main.main(Main.java:1263) However note that I don't see this regression all the time (maybe 3 times out of 5). If someone (Dani, Markus?) who knows this test can isolate the problem, that would be great. Actually, the refactoring test also fails from time to time with the patch. So this is a red herring. Fix released for 3.5M7 (In reply to comment #7) > Actually, the refactoring test also fails from time to time with the patch. So > this is a red herring. I meant it fails from time to time WITHOUT the patch Verified that the problem is fixed. |