dfaure requested changes to this revision. dfaure added a comment. This revision now requires changes to proceed.
Strange, I never had that bug. Note that you can use gdb to get a backtrace for a deadlock, no need for hotspot for that particular task. In fact, hotspot even misled you. tryLock() can't be the problem, it returns immediately ;) (default timeout 0) I guess lock() -- which is the actual blocking method in this code -- is where everything got stuck. Unfortunately you didn't get a backtrace so we can't verify this until it happens again? :( Maybe a stale lock file, but not detected as one by QLockFile, could lead to lock() blocking forever... A recursive call to that method would do that too, but I don't see how that could happen. If you want to introduce some safety against locking forever, it's lock() that should be replaced with tryLock(long timeout). I would make it much more than 5s though, kdeinit startup can take much more than that (imagine a slow system, swapping already, kdeinit starts a number of other processes, and triggers config file migration with kconf_update, etc.). REPOSITORY R271 KDBusAddons REVISION DETAIL https://phabricator.kde.org/D14302 To: jtamate, dfaure, #frameworks Cc: kde-frameworks-devel, michaelh, ngraham, bruns
