thiago added a comment.
In https://phabricator.kde.org/D2545#66904, @thiago wrote: > Commit ad66dbe305cff72443f4d3484191872d56e6dfbb in qtbase did try to solve this by disconnecting the senders when the objects were getting deleted. closeConnection() is called before the thread exits (from QDBusConnectionManager::run), so I don't know how there's still a BlockingQueuedConnection active. > > Is it possible that the service began being watched during destruction? I don't see how that's possible because there's another BlockingQueuedConnection protecting that: the QObject connection is only done in QDBusConnectionPrivate::addSignalHook, which is only run in the QDBusConnectionManager thread. So either the thread was still running, in which case we should have disconnected, or the thread wasn't running and the destroyed() signal should have got disconnected. Here's the other problem: it's possible for threads to simply disappear on Windows. Given that I see "dllmain" in the backtrace (though not DllMain), I can't rule out that this has happened. Qt 5.6 has a workaround to another deadlock caused by Windows. Can you try to cherry-pick 3ec57107cedb154f256e3ad001ea5475cc64fa94 from 5.8? BRANCH master REVISION DETAIL https://phabricator.kde.org/D2545 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: kfunk, vonreth, dfaure Cc: thiago, albertvaka, mutlaqja, arrowdodger, #frameworks
