Open ptzafrir opened 7 years ago
I confirm this issue. I tested it trying to connect to a TiSensorTag.
Any news on a fix?
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.
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!
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
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 callsBluetoothManager::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