<table><tr><td style="">dfaure requested changes to this revision.<br />dfaure added a comment.<br />This revision now requires changes to proceed.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D14302">View Revision</a></tr></table><br /><div><div><p>Strange, I never had that bug.</p>

<p>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)</p>

<p>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? :(</p>

<p>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.</p>

<p>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.).</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R271 KDBusAddons</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D14302">https://phabricator.kde.org/D14302</a></div></div><br /><div><strong>To: </strong>jtamate, dfaure, Frameworks<br /><strong>Cc: </strong>kde-frameworks-devel, michaelh, ngraham, bruns<br /></div>