This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 418101 - [CSS] CTabItemTest.testSelectedFontBold times out on the Mac
Summary: [CSS] CTabItemTest.testSelectedFontBold times out on the Mac
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.4   Edit
Hardware: PC Mac OS X
: P3 major (vote)
Target Milestone: 4.4 M3   Edit
Assignee: Markus Keller CLA
QA Contact: Daniel Rolka CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-26 10:00 EDT by Markus Keller CLA
Modified: 2013-10-03 05:22 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2013-09-26 10:00:27 EDT
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.
Comment 1 Markus Keller CLA 2013-09-26 10:37:27 EDT
> > 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.
Comment 3 Markus Keller CLA 2013-10-03 05:22:51 EDT
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.