- 
    Bug 
- 
    Resolution: Incomplete
- 
     Not Evaluated 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
 
-