Details
-
Bug
-
Resolution: Incomplete
-
P2: Important
-
4.7.0, 4.7.3, 5.15.2
-
None
-
eb1015c7bbf135af3656110a4d112377c1209db8
Description
This problem has been reproduced both with Qt 4.6.3 and Qt 4.7 on Windows.
The attached program demonstrates the bug. The program should never stop updating the screen, but if you stop moving the mouse, outside of the application area, the update will freeze after a short period. Moving the mouse back into the application window will resume the updates.
A, functioning workaround is to add the following one line change to Qt, in qeventdispatcher_win.cpp:
emit aboutToBlock();
(void) d->wakeUps.fetchAndStoreRelease(0); // Added this line
waitRet = MsgWaitForMultipleObjectsEx(nCount, pHandles, INFINITE, QS_ALLINPUT, MWMO_ALERTABLE );
emit awake();
It looks like the problem has to do with this wakeUps latch still being set when the application enters the block state at MsgWaitForMultipleObjectsEx. So, this changes simply says, no matter what the rest of the logic says, it's invalid to ever leave this latch set while entering the blocked state.
In addition, un-commenting the Sleep statements in the program causes the application to hang in a very serious way ( it really gets stuck).
The behavior of the sample program provides strong indication of an internal Qt problem in the area of thread to thread communication, where signals can get frozen, or missed, and the application can enter a deadlock or some form of lock or messaging race condition.
Attachments
Issue Links
- relates to
-
QTBUG-7728 Windows sometimes not redrawing until mouse moved or keyboard pressed on win32
- Closed