sdp_connect fails when Bluetooth adapter is off which leads to the
following leak:
37 bytes in 1 blocks are definitely lost in loss record 68 of 165
at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3B03C4D89E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C64BAE: g_strdup (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x427D5D: bluetooth_connect (bluetooth.c:410)
by 0x426CC9: obc_session_create (session.c:454)
by 0x425693: create_session (manager.c:203)
by 0x43D8A3: process_message.isra.5 (object.c:259)
by 0x3B0701CE85: ??? (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x3B0700FA30: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x43A627: 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)
This reverts commit 8a03376544.
The patch needs to be split up and the gdbus/ changes were bogus
compared to the original commit message.
Conflicts:
Makefile.am
Makefile.obexd
profiles/cyclingspeed/cyclingspeed.c
profiles/heartrate/heartrate.c
src/error.c
Instead of trying to include config.h in each file over the tree and
possibly forgetting to include it, give a "-include config.h" argument
to the compiler so it's guaranteed that a) it will be included for all
source files and b) it will be the first header included.
gdbus/ directory is left out, since it would break other projects using
it.
2,210 (64 direct, 2,146 indirect) bytes in 2 blocks are definitely lost in loss record 150 of 155
at 0x4A0884D: malloc (vg_replace_malloc.c:263)
by 0x3B2900F8A1: sdp_create (sdp.c:3656)
by 0x3B2900FAE0: sdp_connect (sdp.c:4604)
by 0x415902: adapter_reply (bluetooth.c:421)
by 0x3B22C0C429: ??? (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x3B22C0F5E9: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x4059A7: message_dispatch (mainloop.c:76)
by 0x32CD64822A: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x32CD647694: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x32CD6479C7: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x32CD647DC1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x40567F: main (main.c:175)
384 (184 direct, 200 indirect) bytes in 1 blocks are definitely lost in loss record 141 of 157
at 0x4A0884D: malloc (vg_replace_malloc.c:263)
by 0x392E217815: ??? (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x392E218632: dbus_message_new_method_call (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x413AD3: send_method_call (bluetooth.c:87)
by 0x414933: manager_reply (bluetooth.c:496)
by 0x392E20C429: ??? (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x392E20F5E9: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x405767: message_dispatch (mainloop.c:76)
by 0x369E04827A: ??? (in /usr/lib64/libglib-2.0.so.0.3200.3)
by 0x369E0476E4: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.3)
by 0x369E047A17: ??? (in /usr/lib64/libglib-2.0.so.0.3200.3)
by 0x369E047E11: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.3)
There is no much of point to have a user_data if it is always the same
type, besides this code is very inefficient and cause a lookup in the list
of pending calls everytime a reply is received.
