Details
-
Bug
-
Resolution: Incomplete
-
Not Evaluated
-
None
-
4.8.0
-
None
-
Ubuntu Linux 11.04
Description
The event dispatcher of a thread is deleted in:
QMutexLocker locker(&d->mutex); ... locker.relock(); d->terminated = false; QAbstractEventDispatcher *eventDispatcher = d->data->eventDispatcher; if (eventDispatcher) { d->data->eventDispatcher = 0; locker.unlock(); eventDispatcher->closingDown(); delete eventDispatcher; locker.relock(); }
(similar code in qthread_win.cpp)
But not all of its uses are thread-safe. For example
...
if (data->eventDispatcher)
data->eventDispatcher->wakeUp();
QCoreApplication::postEvent locks the post event mutex list, but never does it lock the thread mutex which protects the setting of the eventDispatcher variable.
Same thing in:
void QEventLoop::wakeUp() { Q_D(QEventLoop); if (!d->threadData->eventDispatcher) return; d->threadData->eventDispatcher->wakeUp(); }
And in:
if (eventsMoved > 0 && targetData->eventDispatcher) { targetData->canWait = false; targetData->eventDispatcher->wakeUp(); }
This latter function is called with the post event mutexes locked, but not the QThreadPrivate::mutex mutex.
One could argue that the QEventLoop one isn't supposed to be called from outside the thread (it's not marked as \threadsafe), but QCoreApplication::postEvent is and QObject::moveToThread does not mention a problem with moving to a thread that is exiting.
Attachments
Issue Links
- relates to
-
QTBUG-18434 QObject::deleteLater called from a function scheduled by g_idle_add --> QObject won't get deleted the next time the main loop spins
- Closed