This changes the meaning of "properties_lock" from "lock for D-Bus
properties" to "lock for GObject properties".
The most common problem, and the only one I've reproduced in a regression
test, is name_owner, which can be updated by the thread that owns
the GDBusProxy's main context (i.e. the thread-default main context of
the thread that constructed it) at the same time that a blocking call
is made. When a GDBusProxy is constructed in a thread-pool thread for
short-term use, the main context will typically be the global default
main context (which is actively running in the main thread!), making
this extremely problematic.
The interface info is perhaps a theoretical concern - one thread could
conceivably set it at the same time that another thread uses it, but only
in relatively pathological situations. The current API for this does have
the problem that it returns a borrowed ref, but interface info is
hopefully permanent anyway.
The default timeout is probably only a theoretical concern - it's just an
int, so writes are indivisible, and there's no worry about whether
something has been freed - but to be safe, let's hold the lock for that
too.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=656039
Bug-NB: NB#259760
Signed-off-by: David Zeuthen <davidz@redhat.com>
This removes the need for async_init_get_name_owner_cb to cope with being
called without a real GAsyncResult, and will simplify the addition of
correct thread-locking.
In async_init_data_set_name_owner, use the name_owner parameter instead
of the corresponding member of GDBusProxyPrivate, partly to reduce
pointer-chasing but mainly to avoid needing to hold the lock.
Signed-off-by: David Zeuthen <davidz@redhat.com>
These ought to have thread-locking, and having it in the accessor seems
better than duplicating it here.
Signed-off-by: David Zeuthen <davidz@redhat.com>
If you run:
( cd gio/tests && G_DBUS_DEBUG=all ./gdbus-proxy-well-known-name )
you can see that in the case where the name com.example.TestService isn't
owned yet, the GDBusProxy calls GetAll() with no destination, resulting
in an error reply from the peer (the dbus-daemon itself). That's clearly
not right!
However, if priv->name is NULL, that indicates the special case where we
really do want to talk directly to a peer, instead of via the bus daemon
(most likely to be used on peer-to-peer connections); in that special
case, do call GetAll().
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
This avoids calling g_variant_unref and g_free on uninitialized memory
if PropertiesChanged is received in the creating thread's thread-default
main context's thread, at the same time as releasing the last ref in
another thread. This would result in "goto out" before the variables
freed after that label had been initialized to NULL.
Based on a patch by Simon McVittie, bug 656282
Also add convenience _with_unix_fd_list variants to GDBusConnection,
GDBusProxy and GDBusMethodInvocation types to easily support this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
If we have an expected interface and receive a signal not mentioned in
the interface, simply drop it. This way, the application won't have to
check for the signal itself.
This was pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=642724#c5
Signed-off-by: David Zeuthen <davidz@redhat.com>
If the proxy has an GInterfaceInfo set, validate properties against it
so the application doesn't have to do it.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Looks like we forgot to ref the returned GVariant in
g_dbus_proxy_call_finish().
It's a good question why code using g_dbus_proxy_call() and
g_dbus_proxy_call_finish() worked in the first place - probably the
answer is that no-one really used these APIs.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is really what (API) users expect from GDBusProxy - in
particular, mclasen and I ran into this problem while debugging a
upower issue, see
https://bugzilla.redhat.com/show_bug.cgi?id=624125
In a nutshell, the problem is that polkitd crashes while upower holds
a PolkitAuthority object (which in turns contains a GDBusProxy for the
well-known name org.freedesktop.PolicyKit1). This means that
subsequent calls on the PolkitAuthority (which is translated into
calls into the GDBusProxy) fails since :g-name-owner is NULL.
With this fix, we'll be requesting the bus daemon to launch polkitd
since we will start calling into org.freedesktop.PolicyKit1 as soon as
we notice that there is no owner for this name.
Unfortunately our test suite doesn't cover service activation so there
is no way to reliably test this. I will file a bug about this.
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>
Also emit GDBusProxy::g-properties-changed when dropping (when the
name owner vanishes) or populating (when loading properties) the
property cache.
https://bugzilla.gnome.org/show_bug.cgi?id=623538
Signed-off-by: David Zeuthen <davidz@redhat.com>
If we know the expected interface (e.g. :g-interface-info is set),
then we always warned when calling a method on a different
interface. Don't do that, there's no way the expected interface can
know anything about this method.
Signed-off-by: David Zeuthen <davidz@redhat.com>
The GType for a GVariant is now a fundamental GType instead of a boxed
one so use the right marshaller.
Signed-off-by: David Zeuthen <davidz@redhat.com>
When asynchronously acquiring the DBus connection, assume a reference to
the proxy object, to avoid destroying it in the middle of the operation.
See https://bugzilla.gnome.org/show_bug.cgi?id=621905
