Description Timo Rohrberg 2017-05-03 05:43:38 EDT

Created attachment 268139 [details]
Work around potential race condition.

While working on adapting the Riena build process to Eclipse Tycho, I'm currently fighting with randomly failing UI tests. Examining the source code in detail lets me strongly believe that there's a potential race condition in the class org.eclipse.riena.internal.ui.swt.test.UITestHelper.waitAndDispatch() method which is the cause of those random failures.

Let me explain my assumption in detail: In the org.eclipse.riena.internal.ui.swt.test.UITestHelper.send() method, a new thread is created which sends the given text to the UI of the AUT character by character by posting SWT events. That thread is started right away and the method is then actively waiting for the thread to finish by calling the before mentioned waitAndDispatch() method. The active waiting is done with a while loop spinning as long as the thread is active. To process the events posted by the thread, the while loop constantly calls the SWT Display.readAndDispatch() method. Once the thread terminated, the method also returns and the entire operation of sending a string to the UI is considered to be completed.

However, IMHO, there is one edge case in which this process runs into a race condition leading to the events being posted but not handled by the SWT event loop: If the main thread (= UI thread) executing the waitAndDispatch() method is preempted in favor to the thread posting the events exactly after executing the Display.readAndDispatch() method and the thread posting the events completes its execution in one flow, the main thread will afterwards finish the waitAndDispatch() method without calling Display.readAndDispatch() again. This causes the events posted by the other thread no being processed and the simulated keyboard input never reaches the UI of the AUT.

I was examining the source code for a very long time and did a lot of test executions but unfortunately, was not yet able to rocket-prove my assumption of a race condition. This is mainly because I cannot place console output within the while loop of the waitAndDispatch() method since that tremendously slows down the entire test execution and kills my Jenkins.

However, I temporarily worked around the assumed race condition by calling Display.readAndDispatch() again at the end of the waitAndDispatch() method to ensure that all posted events are correctly processed. With that, I was so far able to successfully execute the tests without a single failure. The attached patch contains the change.

Of course this does still not prove my assumption of a race condition and I also don't like the approach with the body-less while loop. But I would like to have someone else have a look at my assumption and cross-check it.