-
Bug
-
Resolution: Incomplete
-
Not Evaluated
-
None
-
4.8.0
-
None
-
Ubuntu Linux 11.04
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.
- 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
-