Crash due to belated type conversion (maxElementCount)

[bspinner]

Where do you suspect the issue?

Issue in mesh library, e.g. packets being dropped

Version

3.2.0

Describe the issue

Calculation of maxElementCount causes a crash.

Crashes if calculation result is negative because conversion to Int happens after calculation.

In our app this happens when:

0. Provision some devices/nodes
1. Add second provisioner with different address range (2nd provisioner's node will have address from local provisioner's range) and some elements
2. Remove first/local provisioner (results in calls to this and this)
3. Calculation in this line will crash

(so more or less #577)

Proposed fix

I am not sure if just fixing the crash is enough or the whole function could cause issues if unicastAddresses of removed nodes/elements have to be reused in case the provisioner's pool of never used addresses dried up.

Otherwise:

-count = Int(node.primaryUnicastAddress - address)
+count = Int(node.primaryUnicastAddress) - Int(address)

Relevant log output

No response

[philips77]

Add second provisioner with different address range (2nd provisioner's node will have address from local provisioner's range) and some elements

There's an assumption, that each Provisoner gets an address from its own unicast address range. In nRF Mesh app you can't assign an address to a new Provisioner from outside of its range.

The library checks that here: https://github.com/NordicSemiconductor/IOS-nRF-Mesh-Library/blob/e8a91907650d454335e87c57fa0c5c12800a48f9/nRFMeshProvision/Mesh%20API/MeshNetwork%2BProvisioner.swift#L175-L178

[philips77]

Could you provide exact steps how can I reproduce the crash using nRF Mesh app? Or which methods are you calling in your app. I tried the procedure you wrote but it seems to work fine in the app.

I am adding a second provisioner with address 199B, which is in its range, then I remove the local one and no crash.

[bspinner]

Hi @philips77,

sorry, I was mistaken in my previous post. The provisioners get created as you say: with addresses within their range. But after deletion, during sync with an Android device something gets messed up.

We'll check if it's related to the android library or just on our end :)

[philips77]

Btw, this assumption that the provisioner gets a unicast address from its own range is not specified anywhere and other implementations may do this differently. Perhaps this should be fixed at some point.