Crash on tinyb::BluetoothEvent::get_type()

[ptzafrir]

After first connection to a device, when there is no bluez cache for it, trying to use service.find() to look for a characteristic causes SIGSEGV

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x61c1e5e0, pid=1113, tid=1624364128
#
# JRE version: Java(TM) SE Runtime Environment (8.0_65-b17) (build 1.8.0_65-b17)
# Java VM: Java HotSpot(TM) Client VM (25.65-b01 mixed mode linux-arm )
# Problematic frame:
# C  [libtinyb.so.0+0x6f5e0]  tinyb::BluetoothEvent::get_type() const+0x14
#

I think this is caused by a race condition where an event is received from the d_bus and handled in BluetoothEventManager::on_interface_added which in turn calls BluetoothManager::handle_event The following code iterates on the event list on one thread https://github.com/intel-iot-devkit/tinyb/blob/0cb6904ad9ea1846176598dfca7afd1aeb42a50f/src/BluetoothManager.cpp#L209 While the java call to the find method will trigger an addition of an event item to the list in another thread https://github.com/intel-iot-devkit/tinyb/blob/0cb6904ad9ea1846176598dfca7afd1aeb42a50f/api/tinyb/BluetoothManager.hpp#L77

[pierantoniomerlino]

I confirm this issue. I tested it trying to connect to a TiSensorTag.

Any news on a fix?

[pierantoniomerlino]

BTW, to avoid this race condition, the application should wait until the getServicesResolved in BluetoohDevice returns true before issuing a find for a service or characteristic.

[AntistesSacrorum]

Hey I think it's worth to add this behavior to documentation, as fixing the crash doesn't lead to understanding why services are not available immediately after connection.

Thanks!