g_dbus_connection_signal_subscribe with flag G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH doesn't work with an arg0 that is an object path
- which version of GLib are you using?
- Issue initially found on glib 2.72.4
- Reproduced on main branch commit 8f37874f
- which operating system are you using?
- Ubuntu 22.04
- the necessary steps to reproduce the issue
-
Here is a minimal example that does not work as expected:
guint sub_id = g_dbus_connection_signal_subscribe(conn, "org.bluez", "org.freedesktop.DBus.ObjectManager", "InterfacesAdded", "/", "/org/bluez/hci0/", G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH, callback, NULL, NULL);
-
When scanning for Bluetooth devices, each new detected device will cause a signal with the parameters as specified above to be emitted. Here are the relevant messages logged by dbus-monitor. The first is my program subscribing to the signal, and the second is the signal being emitted by BlueZ (truncated to just show first argument):
method call time=1700611463.287944 sender=:1.239 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.bluez',interface='org.freedesktop.DBus.ObjectManager',member='InterfacesAdded',path='/',arg0path='/org/bluez/hci0/'" signal time=1700611464.181315 sender=:1.7 -> destination=(null destination) serial=1040 path=/; interface=org.freedesktop.DBus.ObjectManager; member=InterfacesAdded object path "/org/bluez/hci0/dev_6F_E1_12_8B_2E_1F"
-
Despite everything looking as I would expect in the dbus-monitor output, the callback in my program is never called in response the signal emitted by BlueZ. If I remove the G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH and instead use G_DBUS_CALL_FLAGS_NONE with arg0 as NULL, my callback is called.
-
- the expected outcome
- I would expect the code snippet shown above to receive the emitted signal.
- a description of the behavior
- After digging into this a bit, I found that schedule_callbacks function (gdbusconnection.c) uses g_dbus_message_get_arg0 (gdbusmessage.c) to get arg0 from the emitted signal message, and g_dbus_message_get_arg0 requires that argument 0 is of type G_VARIANT_TYPE_STRING; otherwise, it returns NULL. Is there any reason why it can't also accept an arg0 with type G_VARIANT_TYPE_OBJECT_PATH? Allowing the first argument of the emitted signal to be of type G_VARIANT_TYPE_OBJECT_PATH would seem to match the intended use case for the G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH flag.
- a small, self-contained example exhibiting the behavior
- See the snippet above.