Community
Participate
Working Groups
org.eclipse.team.tests.ccvs.core.subscriber.CVSMergeSubscriberTest.test46007() has failed on Windows with the following stack trace in the last two I-builds, namely I20101025-0901 and I20101025-1300: wait-problem junit.framework.AssertionFailedError: wait-problem at org.eclipse.team.tests.ccvs.core.EclipseTest.waitMsec(EclipseTest.java:1002) at org.eclipse.team.tests.ccvs.core.EclipseTest.setContentsAndEnsureModified(EclipseTest.java:986) at org.eclipse.team.tests.ccvs.core.EclipseTest.setContentsAndEnsureModified(EclipseTest.java:976) at org.eclipse.team.tests.ccvs.core.EclipseTest.appendText(EclipseTest.java:215) at org.eclipse.team.tests.ccvs.core.subscriber.CVSMergeSubscriberTest.test46007(CVSMergeSubscriberTest.java:158) at org.eclipse.team.tests.ccvs.core.EclipseTest.runTest(EclipseTest.java:1448) at org.eclipse.team.tests.ccvs.core.EclipseTest.runBare(EclipseTest.java:1295) 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 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 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:377) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:210) 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:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4059) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3678) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2629) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2593) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2427) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:663) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) 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:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:621) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:576) at org.eclipse.equinox.launcher.Main.run(Main.java:1409) at org.eclipse.equinox.launcher.Main.main(Main.java:1385) at org.eclipse.core.launcher.Main.main(Main.java:34) Given our low activity in the repo recently I guess this is an intermittent failure. Let's wait for pending test results for I20101025-1800.
The same test failed in I20101025-1800.
The test pass when run locally on WindowsXP against CVSNT.
Passed in I20101026-2000...
Passed in I20101027-0800 and I20101027-1300. Marking as invalid.
Happened again in N20101129-2000 last night. Moving to Releng, since we haven't done any changes in that area recently but the test is failing randomly. For other tests that fail in a similar manner see bug 246547 and bug 325553.
The test passed in I20101205-2000 but failed again in I20101206-1300 (on Linux).
Passed on all machines in I20101206-1800.
My current theory is that the once a week clean up for the test repository is not sufficient and there are existing files there which conflict with newly created files in the test suite. I completely cleaned the repository on Friday and there weren't test failures over the weekend. I cleaned the repository again this morning and and adjusted the cron job so that it now runs once a day. Let's see how it works for the rest of milestone week.
Failed in 3.6.x stream in M20101222-0800. (In reply to comment #8) > My current theory is that [...] there are existing files there which conflict with newly > created files in the test suite. How can that be? Each project name is created with a unique suffix based on the current time in ms[1]. Do all testing machines hit the same CVS server? If so, maybe they do create projects with the same names (in the exact same time?!) but that's rather impossible imo. Maybe I should salt the name with a random string to make it even more unique. But again, this sounds crazy to me. More unique than System.currentTimeMillis()? Come on! [1] org.eclipse.team.tests.ccvs.core.EclipseTest.getUniqueTestProject(String)
Failed again in N20110219-2000. Please make the test more robust or delete it as it causes noise in the build results.
I would suggest to make the test invulnerable to this particular failure. I would leave the bug open and log the problem in the build logs when it happens again. It would help to notice whether any Kim's changes in the configuration help.
(In reply to comment #11) Tomek, please make the change.
We haven't seen this one for a while (almost a month) but it hit us again[1]. Before I make the suggested change, a final question to Kim: do you have any idea why may another thread interrupt the test thread[2]? And why it happens occasionally? [1] http://download.eclipse.org/eclipse/downloads/drops/N20110315-2000/testresults/html/org.eclipse.team.tests.cvs.core_win32.win32.x86_6.0.html [2] org.eclipse.team.tests.ccvs.core.EclipseTest.waitMsec(int)
I don't know how this could happen other than if two test machines are trying to access the same file in the repository simultaneously.
Failed again: http://download.eclipse.org/eclipse/downloads/drops/N20110416-2000/testresults/html/org.eclipse.team.tests.cvs.core_win32.win32.x86_6.0.html Please either fix this or disable the test.
Created attachment 196409 [details] Disabling the test Filed bug 346948, scheduled for 3.8 to re-enable it.
Created attachment 196410 [details] mylyn/context/zip
You have my +1. You still need an extra +1 though.
I don't think you need three +1's to disable a test. As long as you have the "test" keyword on the bug it won't show up in the query on the freeze plan.
(In reply to comment #19) > I don't think you need three +1's to disable a test. As long as you have the > "test" keyword on the bug it won't show up in the query on the freeze plan. And PMC approval is also not need to fix a bug during RC3 ;-).
(In reply to comment #20) I thought that only Doc bugs are excluded from the list, but indeed the end-game rules for RC3 say "When your bug appears there [the query], make sure that it gets a review+ or add the 'Documentation', 'example' or 'test' keyword if appropriate". It is a 'test' so Tomek, go ahead.
Fixed in HEAD. Available in builds >=I20110525-0800.
