Avoid QDBusConnection Qt warning message for each KUniqueApplication

David Faure faure at kde.org
Sat Nov 17 17:56:11 GMT 2012


On Saturday 17 November 2012 07:22:34 Thiago Macieira wrote:
> On sábado, 17 de novembro de 2012 10.55.01, David Faure wrote:
> > My current broken patch is
> > http://www.davidfaure.fr/2012/kuniqueapp_broken_fix.diff
> > 
> > The change from QDBusConnectionInterface* to QDBusConnection as the return
> > value of tryToInitDBusConnection() -- which introduces a bit of noise in
> > the  patch -- is only due to the very last hunk: so that we can make the
> > call from parent to child using the private connection rather than
> > sessionBus().
> 
> The part in kuniqueapplication.cpp is evident, but I haven't got a clue what
> you're trying to do in kapplication.cpp. You'll need to explain.

Ah, I left a wrong if() in there. Patch updated.
What I'm doing there is
1) move the registerObject before the registerService, to avoid a possible race;
mostly unrelated to fixing the warning though. I know this works since I'm doing
this in KDBusService (KF5) too. In fact it probably doesn't matter since nothing gets
processed before we go to the event loop, so I could just revert, I guess.
2) re-registerService, to replace the registration done by kuniqueapp on the private
dbus connection. Is this necessary? Should I also close the private connection
explicitely, or it is refcounted? This is what I need help with. Whatever I try, doesn't work.

> The rest looks ok.

Well, it breaks startup...

$ killall kuniqueapptest
$ ./kuniqueapptest
18:38:16 unnamed app(6343) KUniqueApplication::start:
18:38:16 unnamed app(6344) tryToInitDBusConnection: private connection
18:38:16 unnamed app(6344) KUniqueApplication::start: child, registerService "org.kde.kuniqueapptest"
18:38:16 unnamed app(6344) KUniqueApplication::start: Child returns from start() with true
18:38:16 unnamed app(6343) tryToInitDBusConnection: private connection
18:38:16 unnamed app(6343) KUniqueApplication::start: Call /MainApplication newInstance
18:38:17 kuniqueapptest(6344) KApplicationPrivate::init:
18:38:18 kuniqueapptest(6344) KApplicationPrivate::init: QDBusConnection::sessionBus()
18:38:18 kuniqueapptest(6344) KApplicationPrivate::init: register /MainApplication
18:38:18 kuniqueapptest(6344) KApplicationPrivate::init: ok= true
18:38:18 kuniqueapptest(6344) KApplicationPrivate::init: registerService(unique) "org.kde.kuniqueapptest"
Running.
18:38:18 unnamed app(6343): Communication problem with  "kuniqueapptest" , it probably crashed. 
Error message was:  "org.freedesktop.DBus.Error.UnknownObject" : " "No such object path '/MainApplication'" " 

This is really strange, because after this, `qdbus org.kde.kuniqueapptest` works (as well
as `qdbus org.kde.kuniqueapptest /MainApplication newInstance` -- which finishes the unittest correctly.

I debugged it a bit more, and the problem is that the dbus call still ends up
in QDBusConnectionPrivate::socketRead for the *private* dbus connection rather than the public one.
But the registered object is in the other one.

Hence my idea of not registering before the KApp ctor, but this fails because the parent
makes the call before the child is ready. Apparently, if one makes a call before the service
registers, dbus errors immediately, while if one makes a call after the service registers but
before the object is available, the call is queued until the server goes into the event loop.

So we have to register in the child immediately after fork, but somehow I want to handle the
call in the real QDBusConnection instance. Or maybe I could register the object into the
private connection too? But how will this work for other objects being exported to dbus?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121117/4e7ee4e0/attachment.sig>


More information about the kde-core-devel mailing list