GNOME Bugzilla – Bug 704319
Property "v" in DBus interface stops the execution of the daemon
Last modified: 2018-05-24 15:30:54 UTC
Using glib 2.36.3 here. So the setup is quite simple: daemon uses gdbus-codegen generated code to handle the DBus interface; client uses gdbus-codegen generated code to map the DBus objects. I add a new property in the DBus interface with signature "v", e.g.: <property name="StupidProperty" type="v" access="read" /> Actually, my real use case is using a property with signature "(uv)" (kind of a dictionary with a single entry where the first integer is an id which helps to identify also the type of variant). The problem happens both when using "v" and "(uv)". Now, as soon as I add the property in the interface, *without additional code* to set a value in the daemon-side, the daemon will start to crash when the client-side loads the remote object. The daemon log will say: name_lost_cb(): Could not acquire the 'XX' service name g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. What's wrong with a "v" or "(uv)" property in DBus? Am I missing something obvious? Any hints?
Set G_DBUS_DEBUG=all and locate the bits that include the D-Bus message (both text rep and binary rep) that triggers this. I'm assuming the bus daemon disconnects your app because a message is malformed... On a higher level, the way this works is that if a prop is unset, we'll return the "null" value, e.g. 0 for scalers, "" for s, "/" for o, [] for any array, etc. Can't remember what we return for a 'v'.... could be it's. not working as intended.
Created attachment 249344 [details] Log with G_DEBUS_DEBUG=all The problematic property is the "Validity" one, defined as "(uv)".
OK, so for Validity - type '(uv)' - the NUL value per the attachment in comment 2 is Validity': <(uint32 0, <()>)> From https://git.gnome.org/browse/glib/tree/gio/gdbusutils.c#n720 we have /* Could be that the GValue is holding a NULL GVariant - in that case, * we return an "empty" GVariant instead of a NULL GVariant */ if (ret == NULL) { GVariant *untrusted_empty; untrusted_empty = g_variant_new_from_data (type, NULL, 0, FALSE, NULL, NULL); ret = g_variant_ref_sink (g_variant_get_normal_form (untrusted_empty)); g_variant_unref (untrusted_empty); } Ryan assured me - back when I wrote the code - that this is a valid way to get the "empty" GVariant for any type-string. In fact, he insisted that I did this so he didn't have to add something like GVariant *g_variant_new_empty (GVariantType *type); The problem is that while this may be valid in GVariant (is it?), it isn't valid in D-Bus and that's why dbus-daemon(1) disconnects the GDBus application. We can probably work around it by always returning <@i 0> (e.g. a variant containing an integer with the value 0) when a variant is requested.... Ryan?
Btw, please try this with GLib master instead of 2.36.3; for example, this bug fix https://git.gnome.org/browse/glib/commit/gio/gdbusmessage.c?id=113f4abb67620696f63d61d1f22a5be635332b7c might be why you're seeing this problem.
(Or maybe not. I thought the fix was from April 2013, turned out it was from April 2012.)
For my use case, always initializing the "(uv)" to a valid value (e.g. (0, g_variant_new_boolean(FALSE))) works-around the issue for now, regardless of the root problem in gdbus: http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=abce098cfe2ed1b2d922201b20756511a65e5748
Yeah, initializing the property to a GVariant instance known to work with D-Bus surely works.
I'm not sure why dbus-1 can't support zero-tuples (although I do vaguely remember the discussion and being unhappy about the result). You can do about that whatever you like... I don't really have much opinion about this particular piece of code.
With the switch to kdbus and GVariant's on the wire, maybe this will be a non-issue?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME'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.gnome.org/GNOME/glib/issues/731.