Deadlock in kded whith Qt 5.6

[Andreas Hartmetz]

On Dienstag, 19. Januar 2016 10:02:33 CET Aleix Pol wrote:
> On Mon, Jan 18, 2016 at 9:23 AM, David Faure <faure at kde.org> wrote:
> > On Friday 15 January 2016 13:48:14 Aleix Pol wrote:
> >> On Fri, Jan 15, 2016 at 1:02 PM, Aleix Pol <aleixpol at kde.org> 
wrote:
> >> > Hi,
> >> > I realized earlier last week that some of my applications were
> >> > freezing, it turns out it's because my kded is freezing and any
> >> > dbus
> >> > calls there need to time out (they take 30s to time out btw).
> >> > 
> >> > Anyway, here's the backtrace: https://paste.kde.org/pajbfmoh8
> >> > 
> >> > I saw David did something in that direction earlier but I
> >> > couldn't
> >> > spot exactly where's the problem, so I decided to report it here,
> >> > hoping he'd know what's going on. :D
> >> > 
> >> > Thanks!!
> >> > 
> >> > Aleix
> >> 
> >> Now that I know how to report a bug to kded5, I reported it. Here
> >> it
> >> is, for completion:
> >> https://bugs.kde.org/show_bug.cgi?id=358017
> > 
> > Thiago: indeed the BlockingQueuedConnection call from messageFilter
> > to the main thread occasionnally leads to deadlocks, we need your
> > "postpone incoming messages" idea.
> 
> It's good to know there's a plan, would it maybe be possible to expand
> a bit? I'd be interested in looking into it as my system is quite
> unusable and I can expect other people will become soon enough.
> 
I briefly talked about this with David yesterday and looked at the code.
What happened previously in kded5:
- it installs a message filter using libdbus API
- when a message to a not-yet-loaded module comes along, the module
  is loaded on the fly and directly from the message filter function 
  before the message is allowed to continue on its way

What happens now:
- the D-Bus connection lives in its own thread, in order to facilitate 
  using the connection from arbitrary threads in the application
- this puts the message filter in the D-Bus thread
- multithreading issues ensue

At the moment, you can pick between various poisons and eventually you 
have two threads waiting for each other and kded5 is mostly deadlocked.
The suggested solution is probably to *queue* messages to not-yet-loaded 
modules and to continue processing other D-Bus message while the 
required modules for the queued message are loading. That would break 
reasonable expectations about message ordering and blocking the least, I 
guess.

Ceteri censeo...
If you do anything blocking in D-Bus, you are going to have a bad time 
unless you have made sure that it is not so. "What could possibly go 
wrong?" is not good enough. Exceptions are calls to quickly replying 
services that are guaranteed to never make D-Bus calls of their own (*), 
and messages to the D-Bus daemon itself.
Please do not use blocking D-Bus calls unless you REALLY know what you 
are doing.
Now I've shamed myself into writing that documentation patch for QtDBus 
that I have wanted to write and submit since a year or three. It should 
have a big fat warning.
Asynchronous code is more tedious but it is in the general case the only 
correct way to make D-Bus calls.

Regarding the current situation, the synchronous module loading was okay 
before the Qt change unless modules somehow made D-Bus calls to 
something else than the daemon (to register their address) just by being 
loaded.
We have had lots of kded5 issues due to blocking calls over the years 
but I don'r remember seeing module loading in any backtraces.

(*) That is where deadlocks happen - directly or indirectly calling out 
to something that is in turn waiting for you.