The reply to a DBus.Properties.Set() method call should go through the
same D-Bus connection. Thus remove the DBusConnection parameter from the
following functions:
- g_dbus_pending_property_success()
- g_dbus_pending_property_error_valist()
- g_dbus_pending_property_error()
During discovery cleanup, it was attempted to send a DevicesFound()
D-Bus signal for pending found devices, but adapter->discovery was set
to NULL before calling send_devices_found(), therefore it never sent any
signal (and there was a leak of discovery->pending list).
Fixes this memory leak when pairing two LE devices:
==1822== 8 bytes in 1 blocks are definitely lost in loss record 42 of
246
==1822== at 0x482BE68: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==1822== by 0x48869AA: standard_malloc (gmem.c:85)
==1822== by 0x4886E42: g_malloc (gmem.c:159)
==1822== by 0x489B26D: g_slice_alloc (gslice.c:1003)
==1822== by 0x489C10A: g_slist_prepend (gslist.c:265)
==1822== by 0x1855AE: adapter_update_found_devices (adapter.c:2846)
==1822== by 0x191431: btd_event_device_found (event.c:260)
==1822== by 0xBC01001A: ???
==1822==
A list should not be modified while iterating on it, and in this case
the solution is trivial: the code is just trying to free the whole list
with a previous call to profile->device_remove() per list item.
Measurement CCC is written during discovery only in case watcher is
registered and notifications shall be enabled. However, it may happen
that (e.g. during reconnection scenario) notifications are already
enabled on remote but watcher is no longer registered and we will
be receiving unwanted notifications.
This patch makes sure measurement CCC is written to proper value
every time it's discovered during connection.
There is no need to use the stack as the channel now have proper buffer
which can be used to store data to be send.
In addition to that make avctp_send_passthrough to use avctp_send.
In case of multiple session being active the code was registering one
PDU hanlder per AVRCP session and given the session pointer as user data
causing the following:
24 bytes in 1 blocks are definitely lost in loss record 370 of 893
at 0x4A0884D: malloc (vg_replace_malloc.c:263)
by 0x4C803FE: g_malloc (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x12EE9D: avctp_register_browsing_pdu_handler (avctp.c:1259)
by 0x12FD7B: state_changed (avrcp.c:1402)
by 0x12D391: avctp_set_state (avctp.c:403)
by 0x12E6B4: avctp_confirm_cb (avctp.c:871)
by 0x1606A3: server_cb (btio.c:254)
by 0x4C7A824: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x4C7AB57: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x4C7AF51: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x120EA1: main (main.c:551)
To fix this the PDU handlers are now per AVCTP session/channel so each
AVRCP session can register its own handler and pass itself as user
data.
This makes possible to the handler to respond asyncronous as the memory
remains valid after it returns.
In addition to that it uses the MTU to calculate the buffer size
necessary.
If an interface is removed from the root path during the same mainloop
iteration that it was added we need to check for data->added before
doing the check for data->parent == NULL in the remove_interface()
function. Otherwise the added interface doesn't get removed from the
data->added list and will result in accessing freed memory:
==337== Invalid read of size 8
==337== at 0x4F65AFA: dbus_message_iter_append_basic (in /usr/lib64/libdbus-1.so.3.7.1)
==337== by 0x1247B5: append_interface (object.c:556)
==337== by 0x4C8DC5C: g_slist_foreach (gslist.c:840)
==337== by 0x1261F7: process_changes (object.c:594)
==337== by 0x126372: generic_unregister (object.c:997)
==337== by 0x4F69669: ??? (in /usr/lib64/libdbus-1.so.3.7.1)
==337== by 0x4F5CE51: dbus_connection_unregister_object_path (in /usr/lib64/libdbus-1.so.3.7.1)
==337== by 0x125E81: object_path_unref (object.c:1236)
==337== by 0x126136: g_dbus_unregister_interface (object.c:1361)
==337== by 0x14CDF0: service_exit (service.c:581)
==337== by 0x177556: plugin_cleanup (plugin.c:242)
==337== by 0x12221F: main (main.c:559)
==337== Address 0x5bc1550 is 0 bytes inside a block of size 56 free'd
==337== at 0x4A079AE: free (vg_replace_malloc.c:427)
==337== by 0x4C7850E: g_free (gmem.c:252)
==337== by 0x125DB0: remove_interface (object.c:671)
==337== by 0x125E3B: object_path_unref (object.c:1230)
==337== by 0x126136: g_dbus_unregister_interface (object.c:1361)
==337== by 0x14CDF0: service_exit (service.c:581)
==337== by 0x177556: plugin_cleanup (plugin.c:242)
==337== by 0x12221F: main (main.c:559)
