D14302: Don't block forever in ensureKdeinitRunning

[David Faure]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180723/35aba9c1/attachment-0001.html>