Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
Since it is valid for a D-Bus interface / service to add new methods,
signals or properties we must NEVER warn about unknown properties or
drop unknown signals or disallow unknown method invocations when we
have an expected interface.
So this means that the expected_interface machinery is only useful for
checking that the service didn't break ABI.
Also update the docs so it is clear exactly what it means to have an
expected interface.
https://bugzilla.gnome.org/show_bug.cgi?id=660886
Signed-off-by: David Zeuthen <davidz@redhat.com>
==23341== 65 bytes in 3 blocks are definitely lost in loss record 927 of 1,020
==23341== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23341== by 0x4057094: g_malloc (gmem.c:134)
==23341== by 0x40573DB: g_malloc_n (gmem.c:281)
==23341== by 0x40717FC: g_strdup (gstrfuncs.c:101)
==23341== by 0x4147F56: value_lcopy_string (gvaluetypes.c:313)
==23341== by 0x4123F0B: g_object_get_valist (gobject.c:1643)
==23341== by 0x41240FF: g_object_get (gobject.c:1731)
==23341== by 0x804C39E: test_basic (gdbus-proxy.c:522)
Bug #628331.
==23341== 85 (24 direct, 61 indirect) bytes in 1 blocks are definitely lost in loss record 900 of 971
==23341== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23341== by 0x4057094: g_malloc (gmem.c:134)
==23341== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==23341== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==23341== by 0x403A751: g_error_new_valist (gerror.c:54)
==23341== by 0x403AAD4: g_set_error (gerror.c:240)
==23341== by 0x420B807: decode_method_reply (gdbusconnection.c:4774)
==23341== by 0x420C2BA: g_dbus_connection_call_sync (gdbusconnection.c:5188)
==23341== by 0x421B7C9: g_dbus_proxy_call_sync (gdbusproxy.c:2477)
==23341== by 0x804BD89: test_bogus_method_return (gdbus-proxy.c:430)
Bug #628331.
Allow constructing a GDBusProxy for well-known names as discussed here
http://mail.gnome.org/archives/gtk-devel-list/2009-October/msg00075.html
including test cases.
Make it possible to create a GDBusProxy for a GBusType instead of a
GDBusConnection. This requires G_BUS_TYPE_NONE so add that too.
Nuke g_bus_watch_proxy() since one can now more or less use GDBusProxy
for this.
Port gdbus-example-watch-proxy to this new API and include this
example in the GDBusProxy doc page.
Also nuke the GType parameter from the GDBusProxy constructors as
requested here: https://bugzilla.gnome.org/show_bug.cgi?id=621229
Also update the porting guide and other API docs for this change.
Also fix a bug in the signal dispatching code so each subscriber only
get notified once, not N times, for the same signal. Also add a test
case for this.
https://bugzilla.gnome.org/show_bug.cgi?id=621213
Signed-off-by: David Zeuthen <davidz@redhat.com>
This makes it possible to use the cached properties mechanism even if
constructing the proxy with the DO_NOT_LOAD_PROPERTIES flag.
This is useful for cases where you obtain the and track object
properties out-of-band. For example, in udisks, the plan is to have
something like this
Manager.GetObjects (out ao paths, out aa{sa{sv}} all_properties);
Manager.ObjectAdded (o path, a{sa{sv}} all_properties);
Manager.ObjectChanged (o path, a{sa{sv}} all_properties);
Manager.ObjectRemoved (o path, a{sa{sv}} all_properties);
E.g. the first GetObjects() call will return *all* data about *all*
exported objects. Further, this way a client will only need to listen
these three signals (three AddMatch) on the Manager object and it will
never need to do GetAll() etc (e.g. can use DO_NOT_LOAD_PROPERTIES).
(Of course this only works if the client is interested in all
objects... while this is true for udisks it is generally not true for
other D-Bus services).
Also use expected_interface to check for programming errors.
Lots of people been suggesting this. We still use MethodInvocation /
method_invocation for handling incoming method calls so use call()
instead of invoke_method() helps to separate the client and server
facilities. Which is a good thing(tm).
Things compile and the test-suite passes. Still need to hook up
gio.symbols and docs. There are still a bunch of TODOs left in the
sources that needs to be addressed.
Signed-off-by: David Zeuthen <davidz@redhat.com>
