Bug 17353

Summary: Delayed Signals after changing my presence state.
Product: Telepathy Reporter: Stefan Eilers <stefan.eilers>
Component: tp-qtAssignee: Olli Salli <olli.salli>
Status: RESOLVED NOTOURBUG QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: major    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Stefan Eilers 2008-08-29 09:30:21 UTC
If I change the state of my presence the signal "PresencesChanged()" is not sent immediately. It seems that something blocks it until the connection is closed. After disconnecting, the events are delivered to me.

Changes of the presence of my contacts are received immediately.
Comment 1 Olli Salli 2008-08-30 10:55:25 UTC
The TelepathyQt4 library does no processing, queuing or anything else to emissions of that signal, in fact nothing in the library itself is connected to the signal. The signal simply is declared in the proxy class for QtDBus to match signals received over DBus against, and you getting the signals otherwise indicates the signal is declared correctly.

Are you sure you are returning to the Qt event loop properly while waiting for the signal to happen? (or running a separate QEventLoop?) Other such simple issues? Otherwise, the problem likely lies in service space (in the Gabble/TpPresenceMixin implementation).

Of course, a weird QtDBus bug might be a cause, but as QtDBus doesn't in any way unpack complex types (such as the PresencesChanged arguments), I can't see any way it could possibly handle signal emissions in a different fashion in different cases.

In any case, cannot be a bug in TelepathyQt4. Tracking up the problem should be started with running your application with QDBUS_DEBUG=2 ./yourapp, running dbus-monitor, and possibly also running the Telepathy connection manager with debugging enabled (for Gabble, do GABBLE_DEBUG=all telepathy-gabble). That way you can see where in the chain the event is lost.
Comment 2 Olli Salli 2008-08-31 15:55:42 UTC
Actually, I'm now confident that the bug is indeed in QtDBus. I ran into a similar problem today in one of my tests for the Group interface autointrospection, where I only got the reply to a Properties.GetAll call once something else (for example, a group flags change) happened on DBus. Until that, QtDBus seemed not to notice the reply at all (judging from the log). Probably a short read / queue unload issue. I'll look into it.
Comment 3 Olli Salli 2008-08-31 15:56:07 UTC
Actually, I'm now confident that the bug is indeed in QtDBus. I ran into a similar problem today in one of my tests for the Group interface autointrospection, where I only got the reply to a Properties.GetAll call once something else (for example, a group flags change) happened on DBus. Until that, QtDBus seemed not to notice the reply at all (judging from the log). Probably a short read / queue unload issue. I'll look into it together with Thiago.
Comment 4 Olli Salli 2008-09-19 05:41:52 UTC
Ah, forgot to comment here. Bug fix (utilising dbus_connection_set_dispatch_status_function) has been submitted to Trolltech already.

The patch is at http://people.collabora.co.uk/~oggis/qdbus-use-dispatch-status-function.patch for anyone interested. I'm not sure if it's in Qt snapshots yet though.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.