ESTBulkUpdater crashing app on iOS 11


#1

Hey,

Everything works as it should for iOS 10 and lower, when we updated version for iOS 11 we have a strange crash only on devices: Cannot remove an observer <CBPeripheral 0x1c03127e0> for the key path "delegate" from <CBPeripheral 0x1c03127e0> because it is not registered as an observer. Discovered CBPeripheral is my mac mini device, and he is not on a list on your cloud.


I started digging, and it only happens when ESTBulkUpdater is turned on, doesn’t matter if i am using start(withBeaconInfos or start(withCloudSettingsAndTimeout. Can you investigate it please?


#2

Hello @m1entus,

I’ve spotted and issue you’ve experienced. There is a small change in CBCentralManager implementation in iOS 11 i believe. The problem is that starting from this version of OS you should avoid creating two instances of CBCentralManager reporting back to single delegate object. CoreBluetooth is not handling that well what is reflected in random internal crash. This requires slight change in our implementation of beacons discovery. We will post update version of SDK later this week. Sorry for inconvenience!


#3

Hello @m1entus,

After deeper dive into the issue it looks like Apple did some changes in internal CoreBluetooth implementation. Crash appears consistently when multiple instances of CBCentralManager are using different dispatch queues working in parallel. We’ve reported this issue as a bug to Apple and waiting for their fix. In the meantime we’ve released Estimote iOS SDK in version 4.25.3 that fixes ESTBeaconDevice class. We are also working on another, much wider, temporary solution that will prevent this crash in other parts of the Estimote SDK. I will keep you updated.


#4

Hello Marcin, do you mind sharing how did you fix this issue? I’m running into the same issue when implementing multiple bluetooth managers

Thank you


#5

@jlubeck we ended up using a single dispatch queue for all of our CBCentralManagers.


#6

I see, but what if I’m using all 3rd party libraries (like your own being one of them) and I don’t have control on the CBCentralManagers queue setting on initialization?


#7

I don’t have any good advice here unfortunately. You could request the library authors to allow you to use your own dispatch queue. Our github.com/estimote/ios-sdk lib actually already supports it in many places.

Our github.com/estimote/ios-proximity-sdk does not, you can open a feature request for that on the GitHub tracker. You can however access the dispatch queue we’re using via EBSUniversalScanner. defaultCBCentralManagerQueue, and re-use it in your own CBCentralManagers.

I would also encourage you to open an independent bug report with Apple. They more attention we can divert to it, the better chance somebody at Apple will take a look at it.