https://bugs.kde.org/show_bug.cgi?id=509947
--- Comment #3 from Ming Chuan <[email protected]> --- I dug into the stack more and did some test, I think this issue is specific to the "QObject::disconnect: wildcard call disconnects from destroyed signal of ..." error message I mentioned in the previous comment. Here’s what’s happening in the stack trace above: 1. Qt's event handling code generates "QObject::disconnect: wildcard call disconnects from destroyed signal of ..." warning 2. The `LogDockerDock` handles it (because we installed a custom handler with `qInstallMessageHandler`) 3. The `LogDockerDock` updates its text, because the size of text passed a threshold, it triggers some slider change, all these on the same thread. 4. The slider code then tries to enqueue a new event to Qt event loop, however, the warning message generating code in step 1 still holds relevant mutex, causing the deadlock, due to reentrancy. This matches my experiments: if I try to enqueue an event inside the LogDockerDock message handler, it deadlocks immediately. In https://doc.qt.io/qt-6/qtlogging.html#qInstallMessageHandler it requires message handler to be "reentrant", "avoid recursion", and preferably "minimal". Which I think we are violating here in `LogDockerDock`, as updating text in the log docker is pretty complex operation -- You are receiving this mail because: You are watching all bug changes.
