Comment 1 Thomas Watson 2013-12-04 08:39:03 EST

I think the test machine may have been under a heavy load at the time of the failure and we timed out trying to stop the framework.  The testBundleDiscardedWhenClasspathStorageHookInvalidates took 22.513 seconds to fail which is a very long time considering the last nightly build this test took 0.411.  This test only has one place where it "waits" for 5 seconds for the framework to stop.  All other activity is run directly on the main thread.  That indicates it took around 17 seconds just to get to the point where we are going to attempt to stop the framework.

We can keep an eye on this and bump the timeout in the test if the failure happens again.

Comment 2 Dani Megert 2013-12-05 03:07:23 EST

Same tests failed again.

Looks like

http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=60867ec6c03325a77fcd6a6006da38046aea1b7a

and/or

http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=bfae5de40933cd07593087ddcded3fe21cb436c1

reveals the failures. So, is it really OK to tweak the tests or is something wrong with he new code?

Comment 3 Dani Megert 2014-01-03 05:47:24 EST

In N20131229-2000 testBundleNotDiscardedWhenClasspathStorageHookValidates failed:

The framework was not stopped expected:<64> but was:<512>

junit.framework.AssertionFailedError: The framework was not stopped expected:<64> but was:<512>
at org.eclipse.osgi.tests.hooks.framework.AbstractFrameworkHookTests.stop(AbstractFrameworkHookTests.java:113)
at org.eclipse.osgi.tests.hooks.framework.AbstractFrameworkHookTests.restart(AbstractFrameworkHookTests.java:99)
at org.eclipse.osgi.tests.hooks.framework.StorageHookTests.restartFramework(StorageHookTests.java:206)
at org.eclipse.osgi.tests.hooks.framework.StorageHookTests.testBundleNotDiscardedWhenClasspathStorageHookValidates(StorageHookTests.java:56)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:657)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:310)
at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36)
at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32)
at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
at org.eclipse.core.launcher.Main.main(Main.java:34)

Comment 4 Dani Megert 2014-01-07 03:11:59 EST

Again 3 failures in N20140106-2000.

Comment 5 Thomas Watson 2014-01-07 10:17:57 EST

I increased the timeout to see if this happens again.  If it does then it is safe to assume there is a deadlock we need to somehow investigate.  I have looked the logic over before and could not find anything in the framework stop code that jumps out.

I also fixed a bug in stopQuietly that prevented it from actually stopping quietly.

Comment 6 Dani Megert 2014-01-17 08:46:21 EST

2 failed again in N20140116-2000:

http://download.eclipse.org/eclipse/downloads/drops4/N20140116-2000/testresults/html/org.eclipse.osgi.tests_linux.gtk.x86_6.0.html

Comment 7 Thomas Watson 2014-04-22 11:58:16 EDT

As not failed for some time.