No matter if disconnection was reported previously, g_dbus_client_unref()
was always calling service disconnect callback. This patch fix the
following scenario:
1) service disconnects from the bus
2) disconnect callback gets called
3) client calls g_dbus_client_unref(), disconnect callback is called
again.
This patch adds a new gdbus helper to notify the clients that
GetManagedObjects reply was received and the last proxy has been
informed previously by the proxy_added callback.
Commit abfc2b0dd5 attempted to fix a crash
related to improper reference counting, but the main issue was that the
reference was taken only during the function call (which is usually
unnecessary for single thread), but still passed a pointer to
DBusConnection to a function that is called by the mainloop. This left a
window where the DBusConnection can be destroyed.
Fixes this crash on unit/test-gdbus-client:
==32642== Invalid read of size 4
==32642== at 0x690D0A6: dbus_connection_ref (in
/lib/i386-linux-gnu/libdbus-1.so.3.7.6)
==32642== by 0x804CEDB: message_dispatch (mainloop.c:73)
==32642== by 0x684580E: g_timeout_dispatch (gmain.c:4450)
==32642== by 0x6844A75: g_main_context_dispatch (gmain.c:3065)
==32642== by 0x6844E14: g_main_context_iterate.isra.23 (gmain.c:3712)
==32642== by 0x68452FA: g_main_loop_run (gmain.c:3906)
==32642== by 0x804C7D3: client_connect_disconnect
(test-gdbus-client.c:188)
==32642== by 0x6868DB2: g_test_run_suite_internal (gtestutils.c:2067)
==32642== by 0x6868F8D: g_test_run_suite_internal (gtestutils.c:2138)
==32642== by 0x6869320: g_test_run_suite (gtestutils.c:2189)
==32642== by 0x686936B: g_test_run (gtestutils.c:1508)
==32642== by 0x696D4D2: (below main) (libc-start.c:226)
==32642== Address 0x709c6e4 is 140 bytes inside a block of size 144
free'd
==32642== at 0x67E806C: free (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==32642== by 0x692D62E: dbus_free (in
/lib/i386-linux-gnu/libdbus-1.so.3.7.6)
==32642== by 0x690E1C2: ??? (in
/lib/i386-linux-gnu/libdbus-1.so.3.7.6)
==32642== by 0x804AAEC: destroy_context (test-gdbus-client.c:104)
==32642== by 0x6868DB2: g_test_run_suite_internal (gtestutils.c:2067)
==32642== by 0x6868F8D: g_test_run_suite_internal (gtestutils.c:2138)
==32642== by 0x6869320: g_test_run_suite (gtestutils.c:2189)
==32642== by 0x686936B: g_test_run (gtestutils.c:1508)
==32642== by 0x696D4D2: (below main) (libc-start.c:226)
"Warning: if the connection is disconnected or you try to send Unix file
descriptors on a connection that does not support them, the
DBusPendingCall will be set to NULL, so be careful with this."
Check this in g_dbus_send_message_with_reply so that callers don't need
to double check for NULL if g_dbus_send_message_with_reply returned
TRUE.
This also fix crash if passing FD over D-Bus is blocked e.g. by SELinux
policy.
bluetoothd[1894]: profiles/audio/avdtp.c:session_cb()
bluetoothd[1894]: profiles/audio/avdtp.c:avdtp_parse_cmd() Received
SET_CONFIGURATION_CMD
bluetoothd[1894]: profiles/audio/a2dp.c:endpoint_setconf_ind() Source
0x6c5000: Set_Configuration_Ind
bluetoothd[1894]: profiles/audio/avdtp.c:avdtp_ref() 0x6df360: ref=1
bluetoothd[1894]: profiles/audio/a2dp.c:setup_ref() 0x6d32b0: ref=1
process 1894: arguments to dbus_pending_call_set_notify() were incorrect,
assertion "pending != NULL" failed in file dbus-pending-call.c line
636.
This is normally a bug in some application using the D-Bus library.
When disconnecting from D-Bus a message could be recieved with no sender:
Invalid read of size 1
at 0x4A09EE1: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3B03C386B8: g_str_equal (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4065D6: message_filter (watch.c:529)
by 0x3B0700F9E5: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x4052E7: message_dispatch (mainloop.c:76)
by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4038C5: client_proxy_removed (test-gdbus-client.c:902)
by 0x3B03C6B566: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C6B6E5: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
Address 0x0 is not stack'd, malloc'd or (recently) free'd
In case of filter_data having a watch to a service name it may call
dbus_connection_remove_filter twice causing libdbus to abort:
process 24723: Attempt to remove filter function 0x4063e0 user data (nil), but no such filter has been added
To fix this the code will now only attempt to call
dbus_connection_remove_filter once in filter_data_free which is the
counterpart of filter_data_get where dbus_connection_add_filter is called.
at 0x40570C: update_service (watch.c:601)
by 0x40584B: service_reply (watch.c:627)
by 0x3B0700C511: ??? (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x3B0700F740: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x405167: message_dispatch (mainloop.c:76)
by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
Address 0x4c58a30 is 32 bytes inside a block of size 56 free'd
at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3B03C4D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x406102: filter_data_remove_callback (watch.c:378)
by 0x405FC0: g_dbus_remove_watch (watch.c:798)
by 0x40A22B: g_dbus_client_unref (client.c:1227)
by 0x40570B: update_service (watch.c:599)
by 0x40584B: service_reply (watch.c:627)
This fixes double emission of PropertiesChanged introduced by flushing
changes, the flushing can happen during the pending processing so the
pending_prop flag needs to be updated in the beginning and the list of
properties can be freed before g_dbus_send_message as it is not required
anymore.
In some cases the order of the messages is altered when a message is
sent without processing the pending signals first, currently this affect
client_check_order unit test:
/gdbus/client_check_order: **
ERROR:unit/test-gdbus-client.c:795:property_check_order: assertion failed: (g_strcmp0(string, "value1") == 0)
As can be observed the value of the property is not yet updated because the
signal it is still pending, once this fix is applied the test pass:
/gdbus/client_check_order: OK
Note that the flushing only works when g_dbus_send_message is used so
places where dbus_connection_send and other variants are called directly
may still change the order.
Remove proxies and generate proxy_removed callbacks even when there are
no corresponding InterfaceRemoved signals.
This patch fixes having zombie gdbus proxy object when a server
disconnects without sending InterfaceRemoved signals. These objects
may interact with new server instances, for example, making
InterfaceAdded signals of new objects with the same name be filtered
out as duplicated, or staying allocated, but unused, if the new server
doesn't reuse the object paths. Note that as a side-effect, the
lifetime of a gdbus proxy becomes stricter: it lives at most for the
duration of a single connection to a single instance of a server
process.
From D-Bus documentation for dbus_connection_send_with_reply():
"Warning: if the connection is disconnected or you try to send Unix file
descriptors on a connection that does not support them, the
DBusPendingCall will be set to NULL, so be careful with this."
Fix these errors when killing D-Bus daemon with the client still
running:
process 5712: arguments to dbus_pending_call_set_notify() were
incorrect, assertion "pending != NULL" failed in file
../../dbus/dbus-pending-call.c line 596.
This is normally a bug in some application using the D-Bus library.
process 5712: arguments to dbus_pending_call_unref() were incorrect,
assertion "pending != NULL" failed in file
../../dbus/dbus-pending-call.c line 572.
This is normally a bug in some application using the D-Bus library.
Fix this crash if D-Bus exits while the client is still connected to it:
==5570== Invalid read of size 1
==5570== at 0x402D28E: strcmp (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5570== by 0x4070E22: g_str_equal (ghash.c:1704)
==5570== by 0x8055F61: message_filter (client.c:1123)
==5570== by 0x4141500: dbus_connection_dispatch (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==5570== by 0x80506F7: message_dispatch (mainloop.c:76)
==5570== by 0x4081A7E: g_timeout_dispatch (gmain.c:3882)
==5570== by 0x4080D85: g_main_context_dispatch (gmain.c:2539)
==5570== by 0x4081124: g_main_context_iterate.isra.21 (gmain.c:3146)
==5570== by 0x408156A: g_main_loop_run (gmain.c:3340)
==5570== by 0x41BF4D2: (below main) (libc-start.c:226)
==5570== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==5570==
==5570==
Calling g_dbus_client_new followed by g_dbus_client_set_proxy_handlers
cause two calls to GetManagedObjects in a row as GetNameOwner reply is
asyncronously it triggers the second call because the handlers have
been set by g_dbus_client_set_proxy_handlers.
g_atomic_* end up using G_STATIC_ASSERT, causing gcc 4.8 to yell due to
-Wunused-local-typedefs.
gdbus/client.c: In function ‘g_dbus_client_ref’:
/usr/include/glib-2.0/glib/gmacros.h:162:53: error: typedef ‘_GStaticAssertCompileTimeAssertion_2’ locally defined but not used [-Werror=unused-local-typedefs]
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
In case a property did not appear by the time proxy_added was called
property_changed has to be called if it appear latter otherwise the
application will be unaware of it.
When the client uses ObjectManager to init properties, do not call
property changed callbacks. They should only be called once the proxy
added has been successfully signaled since the proxy itself provides
a full copy of available properties.
If we haven't published an interface yet (i.e. it's in the data->added
list), we should just ignore any property changed indications as the
values for the properties will anyway be part of the InterfacesAdded
signal.
The pointer returned by dbus_message_iter_get_signature() must be freed
with dbus_free().
Fixes this memory leak:
==1857== 16 bytes in 1 blocks are definitely lost in loss record 104 of
251
==1857== at 0x402BF52: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==1857== by 0x415E286: dbus_realloc (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==1857== by 0x415E70B: ??? (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==1857== by 0x415F17B: ??? (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==1857== by 0x414CB33: dbus_message_iter_get_signature (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==1857== by 0x8053239: properties_set (object.c:899)
==1857== by 0x5FFFFF: ???
==1857==
If we received a call to ObjectManager.GetManagedObject we should not
include in the response the interfaces in data->added. This is because
it's not guaranteed that those interfaces will trigger an
InterfacesAdded signal, which is the case if the interface is removed in
the same mainloop iteration.
The generated introspection is not supposed to be read as is by human,
so there's no point in printing the indentation or writing more code to
use auto-close tags.
If it's desired to read the raw xml file, user can always use other
tools to transform the output such as "xmllint --format".
This also fixes a missing </property> when property is deprecated.
This flag can be used to mark properties as experimental, marked
properties are disabled by default and can be enabled by setting
G_DBUS_FLAG_ENABLE_EXPERIMENTAL using g_dbus_set_flags.
This flag can be used to mark signals as experimental, marked
signals are disabled by default and can be enabled by setting
G_DBUS_FLAG_ENABLE_EXPERIMENTAL using g_dbus_set_flags.
This flag can be used to mark methods as experimental, marked
methods are disable by default and can be enabled by setting
G_DBUS_FLAG_ENABLE_EXPERIMENTAL using g_dbus_set_flags.
