Hi,

What kind of popup are triggering the freeze ?

That question is being answered on this thread.

@kshegunov Thanks. I can reproduce the same behavior with a single thread.

#include <QtCore> struct Object: QObject{ Q_OBJECT public slots: void foo(){ qDebug() << __LINE__; while(entered) qApp->processEvents(); qDebug() << __LINE__; QEventLoop loop; QTimer::singleShot(1000, &loop, SLOT(quit())); entered = true; loop.exec(); entered = false; qDebug() << __LINE__; } private: bool entered = false; }; int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); Object w; QTimer::singleShot(0, &w, SLOT(foo())); QTimer::singleShot(0, &w, SLOT(foo())); QTimer::singleShot(3000, &a, SLOT(quit())); a.exec(); qDebug() << __LINE__; } #include "main.moc"

In fact, it has nothing to do with multi-threads. I have never studied Qt source code. It seems exec will not return before all slots finish. So, the code actually creates a dead lock.

Here's an example of the errors I got.
http://hastebin.com/qalutirici.coffee

This seems like a false positive or something that isn't in my code (maybe I'm wrong).
In each error I got, the "at" is pointing to a function that isn't part of my code.

@sinjohr I think this things happen. Working with threads is not always a cool path.

According to the documentation, a QEvent::ThreadChange event is sent to the object just before the thread affinity is changed.

You can try to handle the event.

Another option is using the overloaded method

void QCoreApplication::postEvent(QObject * receiver, QEvent * event, int priority)

and use Qt::LowEventPriority.