SyncEvolution started to use D-Bus as IPC mechanism between processes, using a direct D-Bus connection. One of my tests fails when using libdbus: when the peer goes down and the connection is closed, the surviving processes doesn't get an error callback for its pending method calls on that connection. This only matters when "exit on connection loss" is disabled. SyncEvolution disables that because it needs to clean up resp. continue syncing when possible without the peer. It works when using GIO D-Bus, which is the long-term solution for SyncEvolution - except on systems which only have libdbus. I tracked it down to the following sequence of events (1.4 branch): - connection loss is noticed - connection_timeout_and_complete_all_pending_calls_unlocked() queues pre-generated error messages ("timeout_link") and removes the pending method call. - dbus_connection_dispatch() is called and processes the queued error messages. Because there is no pending method call matching the reply anymore (it was removed in the previous step), the message is dropped as "not handled". I'm not sure what the right solution is. Keep canceled method calls? Perhaps in a separate list? Can anyone think of a workaround? I'd like to get SyncEvolution working on legacy Linux distros which won't get libdbus updates.
This is now fixed? Where and how?
It's not. Someone is spamming freedesktop.org bugs with meaningless changes. Their account has been disabled.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/67.
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.