If g_bus_get_sync() fails in authentication (because e.g. the process
uid, doesn't match the expected in EXTERNAL), a secondary call to
g_bus_get_sync() would notice we aren't initialized, and try
to initialize.
The assertion here is just wrong; we now explicitly and clearly handle
both cases where we already have an error, or we already succeeded.
https://bugzilla.gnome.org/show_bug.cgi?id=635694
If specified, the signal subscription is setup client-side but the match
rule is not sent to the server. This allows the caller to manually
register more detailed match rules.
It doesn't really work right now because of a dbus-daemon(1) bug - see
the comment added in the TODO section of gdbusconnection.c. So revert
to old behavior. The downside is a lot of files in /tmp but right now
that's better than not being able to run tests in a loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Without this fix, the ./gdbus-connection test case occasionally fails, see
https://bugzilla.gnome.org/show_bug.cgi?id=629945#c5
like this
/gdbus/connection/basic: OK
/gdbus/connection/life-cycle: **
ERROR:gdbus-connection.c:223:test_connection_life_cycle: assertion failed:
(!quit_mainloop_fired)
cleaning up bus with pid 21794
Aborted (core dumped)
because the callback didn't happen on the same thread as where we are
running the loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Turns out that GDBusWorker will issue callbacks (in its own thread)
even after g_dbus_worker_stop() has been called. This would rarely
happen (and unreffing a connection is even rarer) so only saw this bug
occasionally when running the gdbus-connection test case in a loop.
Fix up this issue by maintaining a set of GDBusConnection objects that
are currently "alive" and do nothing in the callbacks if the passed
user_data pointer is not in this set.
Also attempted to fix up a race condition with
_g_object_wait_for_single_ref_do() and its use of GObject toggle
references - for now, just resort to busy waiting, thereby
sidestepping the toggle reference mess altogether.
Signed-off-by: David Zeuthen <davidz@redhat.com>
==7269== 144 bytes in 6 blocks are definitely lost in loss record 1,282 of 1,325
==7269== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==7269== by 0x4056B74: g_malloc (gmem.c:164)
==7269== by 0x406EDB6: g_slice_alloc (gslice.c:842)
==7269== by 0x406EDFB: g_slice_alloc0 (gslice.c:854)
==7269== by 0x413C627: g_type_create_instance (gtype.c:1867)
==7269== by 0x412276A: g_object_constructor (gobject.c:1480)
==7269== by 0x4121E5D: g_object_newv (gobject.c:1264)
==7269== by 0x4121BD3: g_object_new (gobject.c:1176)
==7269== by 0x417CFB9: g_credentials_new (gcredentials.c:156)
==7269== by 0x41D9DBC: g_unix_credentials_message_deserialize (gunixcredentialsmessage.c:149)
==7269== by 0x41C422C: g_socket_control_message_deserialize (gsocketcontrolmessage.c:198)
==7269== by 0x41BFCE3: g_socket_receive_message (gsocket.c:3289)
==7269== by 0x41D99CE: g_unix_connection_receive_credentials (gunixconnection.c:476)
==7269== by 0x41FA829: _g_dbus_auth_run_server (gdbusauth.c:987)
==7269== by 0x4205DDB: initable_init (gdbusconnection.c:2196)
Bug #629689.
Rework filter functions as per
https://bugzilla.gnome.org/show_bug.cgi?id=624546#c8
This commit breaks ABI. However, this ABI break affects only
applications using filter functions. The only known user of is dconf.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Don't leak the ptr arrays in the map_sender_unique_name_to_signal_data_array
hash table.
==23440== 84 (20 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 920 of 993
==23440== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23440== by 0x4057094: g_malloc (gmem.c:134)
==23440== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==23440== by 0x401D2D0: g_ptr_array_sized_new (garray.c:799)
==23440== by 0x401D2AC: g_ptr_array_new (garray.c:783)
==23440== by 0x420834A: g_dbus_connection_signal_subscribe (gdbusconnection.c:3084)
Bug #628436.
==31063== 98 (24 direct, 74 indirect) bytes in 1 blocks are definitely lost in loss record 946 of 1,136
==31063== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==31063== by 0x4057094: g_malloc (gmem.c:134)
==31063== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==31063== by 0x4092383: g_variant_get_child_value (gvariant-core.c:847)
==31063== by 0x408BE9E: g_variant_get_variant (gvariant.c:709)
==31063== by 0x40903F5: g_variant_valist_get_nnp (gvariant.c:3767)
==31063== by 0x40907A9: g_variant_valist_get_leaf (gvariant.c:3884)
==31063== by 0x4090D10: g_variant_valist_get (gvariant.c:4065)
==31063== by 0x4090E59: g_variant_valist_get (gvariant.c:4100)
==31063== by 0x40911B6: g_variant_get_va (gvariant.c:4296)
==31063== by 0x40910BC: g_variant_get (gvariant.c:4248)
==31063== by 0x4208DAF: invoke_set_property_in_idle_cb (gdbusconnection.c:3676)
Bug #628346.
Turns out we are leaking non-floating GVariant instances returned by
get_property() functions.
Also avoid imprecise language such as "newly-allocated GVariant" as
this doesn't specify whether the variant can be floating or not.
Also see https://bugzilla.gnome.org/show_bug.cgi?id=627974 as it is
very related to this change.
Signed-off-by: David Zeuthen <davidz@redhat.com>
... that is, make it private. This makes sense because users are never
expected to create such objects themselves - only the GDBus core will
need this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Allow modifying a GDBusMessage in a filter function and also add tests
for this. This breaks API but leaves ABI (almost) intact - at least
dconf's GSettings backend (the only big user I know of) will keep
working.
https://bugzilla.gnome.org/show_bug.cgi?id=624546
Signed-off-by: David Zeuthen <davidz@redhat.com>
This prints all GDBusMethodInvocation API usage and is normally used
with the `incoming' option. Example:
# G_DBUS_DEBUG=incoming,return ./polkitd --replace
Entering main event loop
Connected to the system bus
Registering null backend at priority -10
[...]
Acquired the name org.freedesktop.PolicyKit1
[...]
========================================================================
GDBus-debug:Incoming:
<<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
invoked by name :1.26
serial 299
========================================================================
GDBus-debug:Return:
>>>> METHOD ERROR org.freedesktop.PolicyKit1.Error.Failed
message `Cannot determine session the caller is in'
in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
to name :1.26
reply-serial 299
[...]
========================================================================
GDBus-debug:Incoming:
<<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
invoked by name :1.2402
serial 25
========================================================================
GDBus-debug:Return:
>>>> METHOD RETURN
in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
to name :1.2402
reply-serial 25
Signed-off-by: David Zeuthen <davidz@redhat.com>
The D-Bus spec mentions exactly what header fields are required for
various message types. Add tests for this as well.
Also disallow empty interfaces for signals since the D-Bus spec says
this is Verboten already.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Spell out "RECEIVED SIGNAL" instead of "SIGNAL" to emphasize this is
about receiving a signal, not emitting one (which is "SIGNAL
EMISSION"). Also make the "arrows" point in the "right" direction
("<<<<" vs ">>>>") - like this:
========================================================================
GDBus-debug:Signal:
<<<< RECEIVED SIGNAL org.freedesktop.DBus.NameOwnerChanged
on object /org/freedesktop/DBus
sent by name org.freedesktop.DBus
and
========================================================================
GDBus-debug:Incoming:
<<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.EnumerateTemporaryAuthorizations()
on object /org/freedesktop/PolicyKit1/Authority
invoked by name :1.2176
Signed-off-by: David Zeuthen <davidz@redhat.com>
This should make things easier to debug:
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.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Don't do too much work in the finalizer - in particular, there's no
need to send RemoveMatch() messages to the bus daemon since we're
going to sever the connection and the bus will garbage collect
anyway. In this case it crashed the process.
Also add a test case that checks that the appropriate GDestroyNotify
callbacks are called when unreffing a connection with either 1)
exported objects; 2) signal subscriptions or 3) filter functions
.. yes, ideally apps would unregister such callbacks before giving up
their ref but that's not how things work :-)
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is preferable to the current magical solution whereby the serial
is only rewritten if non-zero. In particular, it makes it easier to
send the same message on multiple connections without having to reset
the serial number.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is currently unused but might be useful in the future. For
example, it might be nice with a way to bypass the current queue of
outgoing messages - having a flag enumeration allows us to add a
G_DBUS_SEND_MESSAGE_FLAGS_BYPASS_QUEUE etc. etc.
This commit breaks ABI and API. Users of the (rarely used) API to send
messages will have to port to this new API.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is currently unused but will probably be useful in the
future. For example, we could have a _ARG0_IS_PATH to specify that
arg0 should be used for arg0path.
This commit breaks API and ABI. Users of
g_dbus_connection_signal_subscribe() will need to port to this new
version.
Signed-off-by: David Zeuthen <davidz@redhat.com>
If the subtree introspection function indicates that an interface exists
but then the dispatch function returns a NULL vtable for that interface,
issue a g_warning pointing programmers in the right direction.
Return a NULL terminated C array instead of a GPtrArray
Also, document that %NULL is a permitted return value and clarify its
meaning.
Finally, avoid calling the enumeration function during dispatch when the
G_DBUS_SUBTREE_FLAGS_DISPATCH_TO_UNENUMERATED_NODES flag was given.
... so it is async, cancelable and returns an error. Also provide a
synchronous version.
This is an API/ABI break but it is expected that only very few
applications use this API.
Signed-off-by: David Zeuthen <davidz@redhat.com>
E.g. move these C structures out of public header files and into their
respective C files. Also nuke padding since this is no longer needed.
This leaves only GDBusProxy as an extendable type.
Signed-off-by: David Zeuthen <davidz@redhat.com>
While this a dangerous thing to allow (collissions, reply_serial not
matching up etc.), the added flexibility makes this a good trade-off -
for example, with this feature, it's now a lot easier to build message
routers.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Also add a 'address' G_DBUS_DEBUG option that will print out useful
debug information such as
GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
GDBus-debug:Address: dbus-launch output:
0000: 75 6e 69 78 3a 61 62 73 74 72 61 63 74 3d 2f 74 unix:abstract=/t
0010: 6d 70 2f 64 62 75 73 2d 77 42 41 6f 4b 59 49 52 mp/dbus-wBAoKYIR
0020: 7a 75 2c 67 75 69 64 3d 30 34 30 64 31 33 66 33 zu,guid=040d13f3
0030: 30 61 30 62 35 32 63 32 30 66 36 32 63 34 31 63 0a0b52c20f62c41c
0040: 30 30 30 30 35 30 38 64 00 d2 38 00 00 01 00 40 0000508d..8....@
0050: 05 00 00 00 00 .....
GDBus-debug:Address: dbus-launch stderr output:
14542: Autolaunch enabled (using X11).
14542: --exit-with-session automatically enabled
14542: Connected to X11 display ':0.0'
14542: === Parent dbus-launch continues
14542: Waiting for babysitter's intermediate parent
14542: Reading address from bus
14542: Reading PID from daemon
14542: Saving x11 address
14542: Created window 88080385
14542: session file: /root/.dbus/session-bus/05e508961149264c9b750a4c494aa6f7-0
14542: dbus-launch exiting
GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
and
GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
GDBus-debug:Address: dbus-launch output:
0000: 75 6e 69 78 3a 61 62 73 74 72 61 63 74 3d 2f 74 unix:abstract=/t
0010: 6d 70 2f 64 62 75 73 2d 77 42 41 6f 4b 59 49 52 mp/dbus-wBAoKYIR
0020: 7a 75 2c 67 75 69 64 3d 30 34 30 64 31 33 66 33 zu,guid=040d13f3
0030: 30 61 30 62 35 32 63 32 30 66 36 32 63 34 31 63 0a0b52c20f62c41c
0040: 30 30 30 30 35 30 38 64 00 d2 38 00 00 01 00 40 0000508d..8....@
0050: 05 00 00 00 00 .....
GDBus-debug:Address: dbus-launch stderr output:
14549: Autolaunch enabled (using X11).
14549: --exit-with-session automatically enabled
14549: Connected to X11 display ':0.0'
14549: dbus-daemon is already running. Returning existing parameters.
14549: dbus-launch exiting
GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
Note that things work exactly like libdbus, e.g. from the
dbus-launch(1) man page:
Whenever an autolaunch occurs, the application that had to start a
new bus will be in its own little world; it can effectively end up
starting a whole new session if it tries to use a lot of bus
services. This can be suboptimal or even totally broken, depending
on the app and what it tries to do.
[...]
You can always avoid autolaunch by manually setting
DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default
address if none is set is "autolaunch:", so if any other address is
set there will be no autolaunch. You can however include autolaunch
in an explicit session bus address as a fallback, for example
DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if
the first address doesn't work, processes will autolaunch. (The bus
address variable contains a comma-separated list of addresses to
try.)
Signed-off-by: David Zeuthen <davidz@redhat.com>
This commit adds the following G_DBUS_DEBUG flags
- emission
- incoming
- call
- signal
- payload
https://bugzilla.gnome.org/show_bug.cgi?id=620913
Signed-off-by: David Zeuthen <davidz@redhat.com>
