Community
Participate
Working Groups
org.eclipse.e4.ui.tests.css.swt.CTabItemTest.testSelectedFontBold timed out on the Mac in I20130924-1130, N20130924-2000, and N20130925-2000. (In reply to bug 417928 comment #7) > The timeout is somewhere around > org.eclipse.e4.ui.tests.css.swt.CTabItemTest.spinEventLoop(). In > http://download.eclipse.org/eclipse/downloads/drops4/I20130924-1130/testresults/html/org.eclipse.e4.ui.tests.css.swt_macosx.cocoa.x86_5.0.html , > you can see that testSelectedFontBold took 7077.403s (almost 2h), and > http://download.eclipse.org/eclipse/downloads/drops4/I20130924-1130/testresults/consolelogs/macosx.cocoa.x86_64_7.0_consolelog.txt says > [..] EclipseTestRunner almost reached timeout [..] > and you can see the main thread is spinning in > CTabItemTest.testSelectedFontBold. > In N20130923-2000, the "Bluetooth Keyboard Setup" dialog was also up, but > the CTabItemTest didn't time out.
> > In N20130923-2000, the "Bluetooth Keyboard Setup" dialog was also up, but > > the CTabItemTest didn't time out. Maybe that was just luck. The test also took 4266s to complete. Anyway, CTabItemTest#spinEventLoop() is unsafe since bug 403234, because it calls Display#sleep() without a guarantee that another thread will wake it up. See bug 343308. Note that in the current code, access to done[0] is not synchronized, which could be another problem source.
Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=62b7cf5c93ade21a4dcf2cb134376b41a0bbb4cf
Verified in N20131002-2000. All platforms green. For the records: The event delay mentioned in bug 403234 comment 1 seems to be out of SWT's control, so there's no clear "correct" solution for this problem. In my local testing, a single "Thread.sleep(10);" was always enough to make the tests green. The loop I added is just to increase the probability of success.