diff options
Diffstat (limited to 'tests/auto/corelib/kernel/qeventdispatcher')
| -rw-r--r-- | tests/auto/corelib/kernel/qeventdispatcher/tst_qeventdispatcher.cpp | 67 |
1 files changed, 67 insertions, 0 deletions
diff --git a/tests/auto/corelib/kernel/qeventdispatcher/tst_qeventdispatcher.cpp b/tests/auto/corelib/kernel/qeventdispatcher/tst_qeventdispatcher.cpp index 49c10c6a24..025106a81f 100644 --- a/tests/auto/corelib/kernel/qeventdispatcher/tst_qeventdispatcher.cpp +++ b/tests/auto/corelib/kernel/qeventdispatcher/tst_qeventdispatcher.cpp @@ -67,6 +67,7 @@ private slots: void sendPostedEvents_data(); void sendPostedEvents(); void processEventsOnlySendsQueuedEvents(); + void eventLoopExit(); }; bool tst_QEventDispatcher::event(QEvent *e) @@ -205,10 +206,26 @@ void tst_QEventDispatcher::registerTimer() QVERIFY(timers.foundCoarse()); QVERIFY(timers.foundVeryCoarse()); +#ifdef Q_OS_DARWIN + /* + We frequently experience flaky failures on macOS. Assumption is that this is + due to undeterministic VM scheduling, making us process events for significantly + longer than expected and resulting in timers firing in undefined order. + To detect this condition, we use a QElapsedTimer, and skip the test. + */ + QElapsedTimer elapsedTimer; + elapsedTimer.start(); +#endif + // process events, waiting for the next event... this should only fire the precise timer receivedEventType = -1; timerIdFromEvent = -1; QTRY_COMPARE_WITH_TIMEOUT(receivedEventType, int(QEvent::Timer), PreciseTimerInterval * 2); +#ifdef Q_OS_DARWIN + if (timerIdFromEvent != timers.preciseTimerId() + && elapsedTimer.elapsed() > PreciseTimerInterval * 3) + QSKIP("Ignore flaky test behavior due to VM scheduling on macOS"); +#endif QCOMPARE(timerIdFromEvent, timers.preciseTimerId()); // now unregister it and make sure it's gone timers.unregister(timers.preciseTimerId()); @@ -223,6 +240,12 @@ void tst_QEventDispatcher::registerTimer() receivedEventType = -1; timerIdFromEvent = -1; QTRY_COMPARE_WITH_TIMEOUT(receivedEventType, int(QEvent::Timer), CoarseTimerInterval * 2); +#ifdef Q_OS_DARWIN + if (timerIdFromEvent != timers.coarseTimerId() + && elapsedTimer.elapsed() > CoarseTimerInterval * 3) + QSKIP("Ignore flaky test behavior due to VM scheduling on macOS"); +#endif + QCOMPARE(timerIdFromEvent, timers.coarseTimerId()); // now unregister it and make sure it's gone timers.unregister(timers.coarseTimerId()); @@ -314,5 +337,49 @@ void tst_QEventDispatcher::processEventsOnlySendsQueuedEvents() QCOMPARE(object.eventsReceived, 4); } +void tst_QEventDispatcher::eventLoopExit() +{ + // This test was inspired by QTBUG-79477. A particular + // implementation detail in QCocoaEventDispatcher allowed + // QEventLoop::exit() to fail to really exit the event loop. + // Thus this test is a part of the dispatcher auto-test. + + // Imitates QApplication::exec(): + QEventLoop mainLoop; + // The test itself is a lambda: + QTimer::singleShot(0, [&mainLoop]() { + // Two more single shots, both will be posted as events + // (zero timeout) and supposed to be processes by the + // mainLoop: + + QTimer::singleShot(0, [&mainLoop]() { + // wakeUp triggers QCocoaEventDispatcher into incrementing + // its 'serialNumber': + mainLoop.wakeUp(); + // QCocoaEventDispatcher::processEvents() will process + // posted events and execute the second lambda defined below: + QCoreApplication::processEvents(); + }); + + QTimer::singleShot(0, [&mainLoop]() { + // With QCocoaEventDispatcher this is executed while in the + // processEvents (see above) and would fail to actually + // interrupt the loop. + mainLoop.exit(); + }); + }); + + bool timeoutObserved = false; + QTimer::singleShot(500, [&timeoutObserved, &mainLoop]() { + // In case the QEventLoop::exit above failed, we have to bail out + // early, not wasting time: + mainLoop.exit(); + timeoutObserved = true; + }); + + mainLoop.exec(); + QVERIFY(!timeoutObserved); +} + QTEST_MAIN(tst_QEventDispatcher) #include "tst_qeventdispatcher.moc" |