Deadlock in kded whith Qt 5.6

[Thiago Macieira]

On Thursday 21 January 2016 08:37:38 David Faure wrote:
> > I didn't see any "invoking message spies" of the debug I left. Are you
> > sure
> > this had the hook installed?
> 
> You mean the messageFilter? That's exactly the issue, that it's not getting
> called. Therefore autoload doesn't happen.
> 
> It might be a consequence of your previous commit (1f6fa1f37a14742dd),
> not necessarily a problem in the current patch under test.

I don't see how. The spy hooks are called before the queue would get 
suspended. We can invert the order to see if it helps, but I don't see how it 
would help or hinder. It would make the code more complex.

Can I limit the spy hook to method calls? That is, exclude signals.

> > For that matter, can you apply the attached patch so we also get feedback
> > on the queued delivery?
> 
> With this patch applied, here's one log for the first call
> (autostart+autoload, doesn't work)
> 
> http://www.davidfaure.fr/2016/first_call.txt

This one says "delivery is suspended" a couple of times. But as I said, the 
spy processing happens *before* this, with conditional:

    if (Q_UNLIKELY(qDBusSpyHookList.exists()) && qApp) {

The list exists if you've installed a hook. Is it possible that this is 
happening before the QCoreApplication is created?

Note the race condition: you should install the hook *before* connecting to 
the bus. But even if that were the case, we should still be seeing the spy 
later.

> and one log for the second call (kded already started, autoload works)
> 
> http://www.davidfaure.fr/2016/second_call.txt

This one shows "invoking message spies"
-- 
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