Describe the bug
Repeatedly toggling a RileyLink switch on and off in any pump view that uses RileyLinks (MinimedKit, OmniKit, OmnipodKit with Omnipod Classic pods) will eventually crash the Loop or any OS DIY app. The crash is always an "unrecognized selector sent to instance 0x8000000000000000" in the one line RileyLinkBluetoothDeviceProvider.shouldConnect() func. This seems to be long standing issue.
Pete Schwab observed in private DM:
Yes, looks like threading. The comment above RileyLinkBluetoothDeviceProvider.autoConnectIDs says access should be isolated to centralQueue, but there are public accessors like connectingCount and shouldConnect that can be accessed without protection.
Attach an Issue Report
Sample Xcode screenshot after a MinimedKit crash:
Sample Xcode screenshot after an OmniKit crash:
Sample Xcode screenshot after an OmnipodKit with Omnipod Classic crash:
To Reproduce
Steps to reproduce the behavior:
- Use Add Pump to select Minimed, Omnipod, or All Omnipod Types (Omnipod Classic)
- Configure the pump with defaults values, selecting a powered up RileyLink, and then go to the pump view (e.g., for pods Cancel out of the Pair Pod view). When testing for OmniKit or OmnipodKit Omnipod Classic, no pod is actually needed.
- Repeated quickly toggle a RileyLink switch on and off until the app crashes. May happen pretty quickly or it might take a couple of minutes.
Expected behavior
Loop should never crash
Screenshots
See Xcode screenshots above. NA for app.
Phone
Probably doesn't matter. Reproduced on a iPhone 13 Pro Max running iOS 26.5.2 and an iPhone 14 running iOS 18.7.8
Loop Version
Probably doesn't matter. Reproduced with Loop v3.14.3 dev.
CGM
N/A
Pump
Eros or Minimed, both of which use a RileyLink for basic pump communication.
Additional context
Reproduced with traditional RileyLinks and OrangeLinks.
It is possible to crash the app doing the repeated RileyLink toggling in the RileyLink Setup views during pump setup, but it has seemed more difficult there at times (never got it to occur there for MinimedKit).
Have seen this crash in both Loop and Trio.
Describe the bug
Repeatedly toggling a RileyLink switch on and off in any pump view that uses RileyLinks (MinimedKit, OmniKit, OmnipodKit with Omnipod Classic pods) will eventually crash the Loop or any OS DIY app. The crash is always an "unrecognized selector sent to instance 0x8000000000000000" in the one line RileyLinkBluetoothDeviceProvider.shouldConnect() func. This seems to be long standing issue.
Pete Schwab observed in private DM:
Yes, looks like threading. The comment above RileyLinkBluetoothDeviceProvider.autoConnectIDs says access should be isolated to centralQueue, but there are public accessors like connectingCount and shouldConnect that can be accessed without protection.
Attach an Issue Report
Sample Xcode screenshot after a MinimedKit crash:
Sample Xcode screenshot after an OmniKit crash:
Sample Xcode screenshot after an OmnipodKit with Omnipod Classic crash:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Loop should never crash
Screenshots
See Xcode screenshots above. NA for app.
Phone
Probably doesn't matter. Reproduced on a iPhone 13 Pro Max running iOS 26.5.2 and an iPhone 14 running iOS 18.7.8
Loop Version
Probably doesn't matter. Reproduced with Loop v3.14.3 dev.
CGM
N/A
Pump
Eros or Minimed, both of which use a RileyLink for basic pump communication.
Additional context
Reproduced with traditional RileyLinks and OrangeLinks.
It is possible to crash the app doing the repeated RileyLink toggling in the RileyLink Setup views during pump setup, but it has seemed more difficult there at times (never got it to occur there for MinimedKit).
Have seen this crash in both Loop and Trio.