If there's a signal watch that's also watching for name
(data->name_watch) currently we are trying to remove the message_filter
twice since we may have the following call chain:
filter_data_remove_callback()
filter_data_free()
g_dbus_remove_watch()
filter_data_remove_callback()
filter_data_free()
dbus_connection_remove_filter()
dbus_connection_remove_filter()
Because of this we can't currently watch for signals passing the bus
name. After this patch we don't have this issue anymore.
We fix it by removing the filter before calling filter_data_free() if we
are the last filter_data and thus avoid calling
dbus_connection_remove_filter() twice.
Even though service watches accepted a "destroy" callback, they were
being ignored. This fix properly pass them along so they are called when
the watch is removed.
Address an issue in which the daemon incorrectly handles D-Bus main
loop timeouts by only removing timeouts that are not enabled when
D-Bus requests a timeout removal.
generate_introspection_xml generates the root <node> tags with a
'name' attribute. This seems to be a valid attribute but it is not
consistent with the way the D-Bus daemon generates empty nodes.
For example if we register "/foo/bar", D-Bus daemon will generate for
"/foo" a introspection which looks like this:
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
<node name="bar"/>
</node>
and generate_introspection_xml generates for "/foo/bar":
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node name="/foo/bar">
</node>
Just don't add the 'name' attribute to the root node. The GLib
binding for D-Bus does it the same way.
Assume there is only one object registerd at "/". If we add a new
object at "/foo/bar" the introspection of "/" has to be updated. A new
node has to be added at "/".
invalidate_parent_data stops invaldating the whole path because the
boolean return value of dbus_connection_get_object_path_data is used
wrong.
If we get a TRUE just go on down in the path, if FALSE is return
dbus_connection_get_object_path_data has run out of memory.
This patch was generated by the following semantic patch
(http://coccinelle.lip6.fr/)
// <smpl>
@fix disable is_null,isnt_null1@
expression *E;
@@
- !E
+ E == NULL
// </smpl>
We where not dispatching data when a bus disconnects which cause
Disconnected signal to not be processed and thus causing the process to
either not exit or to not trigger callbacks registered with
g_dbus_set_disconnect_function.
To fix this now we always schedule a dispatch which will make sure data
still not processed will make its way to the proper handlers even if
disconnected.
Pending call should be removed if the watch is removed since the
application no longer expect that to be reached and may already freed the
data associated with it.
The bus name should be resolved when adding a watch by service name since
messages do always come with sender set to owner's bus name, also it
should listen to owner updates since it can change without invalidating
the watch.
In the case that parent path data needs to be invalidated we shouldn't
stop at the immediate parent if it doesn't have our own handler
registered but should continue upwards in the tree until we reach root
or our own handler.
This was triggering an assert inside libdbus when the timeout inside
the leaking pending call expired. The assert said that we were trying
to remove an nonexistent timeout.
filter_data_find return the first data registered in this case so there is
no guarantee that it return the same data as passed to
filter_data_remove_callback which is the one that should be removed.
The fix is to simple cache the connection removing the correct data before
checking if there is any filter left.
Timeouts should also be removed in the remove_timeout callback in
addition to the timeout_handler_free function. This is how dbus-glib
does it and it seems to prevent crashes in certain situations.
Current implementation of libdbus Request name is blocking, consequently
the first incomming message that triggered the service autostart is not
being processed properly.
Previously it was a specific case, now introspection is just another
interface, which is always implemented. It is registered/unregistered
when an object path is referenced first/last.
gdbus was only adding a message filter for the very first connection given
by the user, this caused a bug in agent registration since it has a diffent
connection than previous watches it won't detect agent disappearing from the
bus.
