fix segfaults due to races & missing adapter

During start up, there are races between the
bluetooth, persistence, bluetooth-map and
bluetooth-pbap bindings; on top of it, in the
case there's no bluetooth controller in the system,
various key parameters can exhibit a null value.
The combination of these races and the lack of
bluetooth controller can manifest in a number of
segfaults in the bluetooth binding (it's very easy
to reproduce on qemu).

This commit brings in several changes to make the
bluetooth binding resilient to the races and lack
of bluetooth controller:
* on startup, retrieve the default adapter from
the persistence binding from the init thread
* store the system default adapter in the service
init data structure, and store the active adapter
in the bluetooth state structure.
* update get_default_adapter to return value
obtained from persistence biding, without further
processing;
* add guards to make sure the userdata retrieved
from the application framework is valid;
* on verbs processing, ensure the caller provides
an adapter to apply the verb to, or that at least
there's a valid adapter associated to the
bluetooth state structure;
* initialize agent_data's device_path following free
operation;
* add guards for mediaplayer_path.

Bug-AGL: SPEC-3301
Signed-off-by: Raquel Medina <raquel.medina@konsulko.com>
Change-Id: Ia5a0dc9a61024ff43cd247216d0dff6918046f7e

1 files changed, 1 insertions, 1 deletions

diff --git a/binding/bluetooth-util.c b/binding/bluetooth-util.c
index 8a50731..21bd0df 100644
--- a/binding/bluetooth-util.c
+++ b/binding/bluetooth-util.c
@@ -1048,7 +1048,7 @@ gchar *return_bluez_path(afb_req_t request) {
 	const char *device, *tmp;
 
 	call_work_lock(ns);
-	adapter = adapter ? adapter : ns->default_adapter;
+	adapter = adapter ? adapter : ns->adapter;
 	call_work_unlock(ns);
 
 	device = afb_req_value(request, "device");