Community
Participate
Working Groups
The test has been failing for a few days on all 3 platforms. http://download.eclipse.org/eclipse/downloads/drops4/I20120604-1900/testresults/html/org.eclipse.jdt.ui.tests_linux.gtk.x86_6.0.html http://download.eclipse.org/eclipse/downloads/drops4/I20120604-1900/testresults/html/org.eclipse.jdt.ui.tests_macosx.cocoa.x86_5.0.html http://download.eclipse.org/eclipse/downloads/drops4/I20120604-1900/testresults/html/org.eclipse.jdt.ui.tests_win32.win32.x86_7.0.html
See also bug 380912.
The tests pass locally.
Copying the first two win32 test results, since the links will expire soon. testJavaEditorClose Success testTextEditorClose Failure: Expected instance count: 0, actual: 1 Element 0 org.eclipse.ui.editors.text.TextEditor org.eclipse.search2.internal.ui.text2.FindInFileActionDelegate#fEditor -> org.eclipse.ui.editors.text.TextEditor@87e435 org.eclipse.ui.internal.PluginAction#delegate -> org.eclipse.search2.internal.ui.text2.FindInFileActionDelegate@4ccee5 java.lang.Object[127] -> org.eclipse.ui.internal.WWinPluginAction@1a1d58b java.util.ArrayList#elementData -> [Ljava.lang.Object;@1dbe3d2 org.eclipse.ui.internal.WWinPluginAction#staticActionList -> [org.eclipse.ui.internal.WWinPluginAction@d28057, org.eclipse.ui.internal.WWinPluginPulldown@1e7f62 java.lang.Class -> class org.eclipse.ui.internal.WWinPluginAction junit.framework.AssertionFailedError: Expected instance count: 0, actual: 1 Element 0 org.eclipse.ui.editors.text.TextEditor org.eclipse.search2.internal.ui.text2.FindInFileActionDelegate#fEditor -> org.eclipse.ui.editors.text.TextEditor@87e435 org.eclipse.ui.internal.PluginAction#delegate -> org.eclipse.search2.internal.ui.text2.FindInFileActionDelegate@4ccee5 java.lang.Object[127] -> org.eclipse.ui.internal.WWinPluginAction@1a1d58b java.util.ArrayList#elementData -> [Ljava.lang.Object;@1dbe3d2 org.eclipse.ui.internal.WWinPluginAction#staticActionList -> [org.eclipse.ui.internal.WWinPluginAction@d28057, org.eclipse.ui.internal.WWinPluginPulldown@1e7f62 java.lang.Class -> class org.eclipse.ui.internal.WWinPluginAction at org.eclipse.jdt.ui.leaktest.LeakTestCase.assertInstanceCount(LeakTestCase.java:127) at org.eclipse.jdt.ui.tests.leaks.JavaLeakTest.internalTestEditorClose(JavaLeakTest.java:324) at org.eclipse.jdt.ui.tests.leaks.JavaLeakTest.internalTestEditorClose(JavaLeakTest.java:293) at org.eclipse.jdt.ui.tests.leaks.JavaLeakTest.testTextEditorClose(JavaLeakTest.java:90) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:501) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:259) at org.eclipse.test.UITestApplication$2.run(UITestApplication.java:197) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4144) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) at org.eclipse.test.UITestApplication.runApplication(UITestApplication.java:140) at org.eclipse.test.UITestApplication.run(UITestApplication.java:62) at org.eclipse.test.UITestApplication.start(UITestApplication.java:212) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) 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:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) at org.eclipse.core.launcher.Main.main(Main.java:34)
I took a screenshot and that looked the same as when running the tests locally (Java perspective crammed in the top left corner on top of the Welcome screen). However, I found that FindInFileActionDelegate is never instantiated at all when running the tests locally. So one part of the problem seems to be that the org.eclipse.search plug-in is activated prematurely on Hudson. http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=86960bf58dd599162f33a0c7973185aed42e88e2 to confirm that.
> However, I found that FindInFileActionDelegate is never instantiated at all > when running the tests locally. So one part of the problem seems to be that > the org.eclipse.search plug-in is activated prematurely on Hudson. org.eclipse.search is activated on Hudson, but that's not enough to reproduce the issue. Adding this line also activates the bundle, but doesn't instantiate the FindInFileActionDelegate: PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage() .showView("org.eclipse.search.ui.views.SearchView"); Possible next steps: - download the test framework and try to run locally - add logging code to FindInFileActionDelegate to see who instantiates it
> However, I found that FindInFileActionDelegate is never instantiated at all > when running the tests locally. So one part of the problem seems to be that > the org.eclipse.search plug-in is activated prematurely on Hudson. That was not the issue. The search plug-in always gets activated by the ReferenceTracker iff you run the whole LeakTestSuite (and not just the JavaLeakTest as I did locally). > - download the test framework and try to run locally Could reproduce the leak in testJavaEditorClose(). Shortest paths from GC roots: +---org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor +---activePart of org.eclipse.ui.internal.expressions.ActivePartExpression | +---[1] of java.lang.Object[2] [JNI Global] +---fEditor of org.eclipse.search2.internal.ui.text2.FindInFileActionDelegate | +---delegate of org.eclipse.ui.internal.WWinPluginAction | +---[48] of java.lang.Object[64] | +---listeners of org.eclipse.core.runtime.ListenerList | +---listeners of org.eclipse.ui.internal.e4.compatibility.SelectionService | +---selectionService of org.eclipse.ui.internal.WorkbenchWindow | +---[0] of java.lang.Object[13] | +---data of org.eclipse.swt.widgets.Shell [JNI Global] +---fEditor of org.eclipse.search2.internal.ui.text2.FindInProjectActionDelegate | +---delegate of org.eclipse.ui.internal.WWinPluginAction | +---[49] of java.lang.Object[64] | +---listeners of org.eclipse.core.runtime.ListenerList | +---listeners of org.eclipse.ui.internal.e4.compatibility.SelectionService | +---selectionService of org.eclipse.ui.internal.WorkbenchWindow | +---[0] of java.lang.Object[13] | +---data of org.eclipse.swt.widgets.Shell [JNI Global] It looks like the problem is that the intro view sometimes loses focus. Closing the intro view solved the problem on my machine, so let's try this first: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=ecea7d4dd342b20be6335d3beb671154ec4e08f7
Closing the intro view solved the problem. Given that I could only reproduce the problem in the automated test setup, but not even when running locally with the intro view visible, I don't think it's worth spending more time to investigate this. Solution in the test (also brings the test closer to real world scenarios): IIntroManager introManager= PlatformUI.getWorkbench().getIntroManager(); introManager.closeIntro(introManager.getIntro());
Cherry-picked the fix into 'R3_8_maintenance' with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=08453f6acb0eebfa43b19bf5bbfb9b2526352d1f
Verified in M20121114-1000 and M20121114-1200.
With Object Teams in the loop I see 15 failures in this suite, where I'm not sure if/how I could have caused this. Same pattern: in the IDE tests are green, in headless build they consistently fail. I'm using JDT/UI latest from master. Do you have any advice how to investigate? Like: how did you take the screenshots? I basically see 2 patterns of chains from GC root: Basic: ------- org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor org.eclipse.search2.internal.ui.text2.FindInFileActionDelegate#fEditor -> org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor@36c199d6 org.eclipse.ui.internal.PluginAction#delegate -> org.eclipse.search2.internal.ui.text2.FindInFileActionDelegate@3d85f2d java.lang.Object[139] -> org.eclipse.ui.internal.WWinPluginAction@6cfad9cb java.util.ArrayList#elementData -> [Ljava.lang.Object;@52f621d0 org.eclipse.ui.internal.WWinPluginAction#staticActionList -> [org.eclipse.ui.internal.WWinPluginAction@229d7e43, org.eclipse.ui.internal.WWinPluginAction@4960af java.lang.Class -> class org.eclipse.ui.internal.WWinPluginAction ==> Isn't this the exact failure from comment 3? *CloseOneOfTwo: --------------- (not sure which one is the leak): junit.framework.AssertionFailedError: Expected instance count: 1, actual: 2 Element 0 org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor org.eclipse.jdt.internal.ui.text.JavaReconciler#fTextEditor -> org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor@2b5cf3db org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread#this$0 -> org.eclipse.jdt.internal.ui.text.JavaReconciler@5cbe8bac java.lang.Thread[20] -> Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] java.lang.ThreadGroup#threads -> [Ljava.lang.Thread;@3d019f69 java.lang.Thread#group -> java.lang.ThreadGroup[name=main,maxpri=10] org.eclipse.osgi.framework.eventmgr.EventManager#thread -> Thread[Framework Event Dispatcher: Equinox Container: e0754108-cfec-0013-1863-d7e9c75ae72d,5,main] org.eclipse.osgi.internal.framework.EquinoxContainer#eventManager -> org.eclipse.osgi.framework.eventmgr.EventManager@58680fca org.eclipse.osgi.internal.loader.BundleLoader#container -> Equinox Container: e0754108-cfec-0013-1863-d7e9c75ae72d org.eclipse.osgi.internal.loader.EquinoxClassLoader#delegate -> org.eclipse.jdt.ui.tests_3.10.0.I20140604-2000 org.eclipse.osgi.internal.loader.EquinoxClassLoader -> org.eclipse.osgi.internal.loader.EquinoxClassLoader@6f469aef[org.eclipse.jdt.ui.tests:3.10.0.I20140 Element 1 org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor org.eclipse.ui.texteditor.BasicTextEditorActionContributor#fActiveEditorPart -> org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor@7e071f1 org.eclipse.ui.internal.EditorActionBars#editorContributor -> org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditorActionContributor@3806f23 org.eclipse.ui.internal.PartSite#actionBars -> org.eclipse.ui.internal.EditorActionBars@6bb97224 org.eclipse.ui.part.WorkbenchPart#partSite -> PartSite(id=org.eclipse.jdt.ui.CompilationUnitEditor,pluginId=org.eclipse.jdt.ui,registeredName=Jav org.eclipse.jdt.internal.ui.text.JavaReconciler#fTextEditor -> org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor@2b5cf3db org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread#this$0 -> org.eclipse.jdt.internal.ui.text.JavaReconciler@5cbe8bac java.lang.Thread[20] -> Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] java.lang.ThreadGroup#threads -> [Ljava.lang.Thread;@3d019f69 java.lang.Thread#group -> java.lang.ThreadGroup[name=main,maxpri=10] org.eclipse.osgi.framework.eventmgr.EventManager#thread -> Thread[Framework Event Dispatcher: Equinox Container: e0754108-cfec-0013-1863-d7e9c75ae72d,5,main] org.eclipse.osgi.internal.framework.EquinoxContainer#eventManager -> org.eclipse.osgi.framework.eventmgr.EventManager@58680fca org.eclipse.osgi.internal.loader.BundleLoader#container -> Equinox Container: e0754108-cfec-0013-1863-d7e9c75ae72d org.eclipse.osgi.internal.loader.EquinoxClassLoader#delegate -> org.eclipse.jdt.ui.tests_3.10.0.I20140604-2000 org.eclipse.osgi.internal.loader.EquinoxClassLoader -> org.eclipse.osgi.internal.loader.EquinoxClassLoader@6f469aef[org.eclipse.jdt.ui.tests:3.10.0.I20140 ==> Which element is the bug? - if Element 0, JavaReconciler looks suspicious (should tests wait until the latest reconcile is finished?) - if Element 1, is CompilationUnitEditorActionContributor to blame? Any hints for investigation appreciated.
> Like: how did you take the screenshots? Like this: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/org.eclipse.jdt.ui.tests/leaks/org/eclipse/jdt/ui/tests/leaks/JavaLeakTest.java?id=1b9f11442324939f010945719d52712adf30c457 The ScreenshotTest class is here: http://git.eclipse.org/c/platform/eclipse.platform.text.git/tree/org.eclipse.ui.workbench.texteditor.tests/src/org/eclipse/ui/workbench/texteditor/tests/ScreenshotTest.java > Any hints for investigation appreciated. Sorry, no good hints. But IIRC, LeakTestCase just prints one backtrace to an object, so the trace the test prints out may not be the interesting one.
I've done some more experiments and since I don't (yet) have any indications that Object Teams causes the leaks, I'm dumping my findings here: It happens consistently during headless tests on build.eclipse.org (original JDT/UI LeakTestSuite against SDK with Object Teams). I could *not* reproduce locally, even when running the tests headlessly (tried real display as well as vnc). - machines used: two linux boxes (x86 pae), one windows 7 box (x86_64) On build.eclipse.org the failure equally occurs using - /shared/common/jdk1.7.0_51 - /shared/common/jdk1.8.0_x64-latest However, when re-using the workspace from a previous run, I see The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes. and the failures do NOT occur. So I thought maybe -clean avoids the issue, but running tests on fresh workspace with explicit "-clean" is still broken. Since I have a consistent repro, I'm open to suggestions for further experiments...
