Deadlock in kded whith Qt 5.6

[Thiago Macieira]

On Tuesday 19 January 2016 15:56:47 you wrote:
> 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

QtDBus API. In fact, it's QtDBus API that exists and has existed only for kded 
(and now kiod).

> - 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

Because the new QtDBus code assumes that certain functions will always be 
called from any-thread-but-QDBusConnectionManager's, as the code is very 
careful to not ever call to user code in the manager's thread. The spy 
function breaks that promise and I didn't catch it when designing the threaded 
model.

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

Actually, we'll queue them all, since we don't know which messages trigger 
loading and which ones don't. So for every incoming message, we'll call out to 
the spy function in the main thread and, after it returns, we'll reinject the 
message into the normal QtDBus processing.

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

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358