NRF_MESH_ASSERT in reliable_timer_cb() [access_reliable.c]

[kcarey]

There is a potential for the NRF_MESH_ASSERT(m_reliable.next_timeout_index < ACCESS_RELIABLE_TRANSFER_COUNT) to fire on line 170 of access_reliable.c if the following conditions are met:

• 2 (or more) simultaneous reliable message timeouts
• The reliable message handler in timer slot 0 reschedules the reliable message
• The reliable message handler in timer slot 1 does not reschedule the reliable message

Because the timeout for the re-added reliable message will be greater than the reliable message in slot 1 (since that timeout is in the past), m_reliable.next_timeout_index does not get updated from its initial 0xFFFF in reliable_timer_cb(). After handling all of the callbacks, the timeout handler checks to see if there are any active timers, which there will be since the first reliable message re-added itself. In this case, it updates the next interval from the incorrect m_reliable.next_timeout_index.

Possible fix:

There is already a function for finding the next earliest timeout index, so calling this instead of relying on m_reliable.next_timeout_index being set correctly should prevent this from causing an assert.

I am using Mesh SDK v4.2, but I believe this issue was present in previous versions as well.

[tesc]

Hi,

Thank you for the detailed bug report! Is there a way to reproduce this issue, to demonstrate that it asserts at the given location? That is, do you have an application that runs on standard hardware (such as nRF52 DK), for easily reproducing?

This happens when different models use reliable messages at the same time, and timeout also happens at the same time, for those two models?

I will file a bug report in our internal tracker.

Regards,
Terje

[kcarey]

Hi Terje,

Thanks for your response! Unfortunately I do not have a good demo for standard hardware at the moment, but one could be made fairly quickly if that would be helpful. The demo application would have 2 models, one of which continuously sends reliable messages and reschedules the message if the reliable message times out. The other model would send reliable messages once in a while and would not reschedule the message if the reliable message times out.

You are correct, this happens when different models are sending reliable messages at the same time and the timeout happens at the same time for those two models. The tricky part in reproducing is that the callback for the reliable message in timer slot 0 needs to try re-sending the reliable message while the callback for the reliable message in timer slot 1 does not try to re-send the reliable message.

[tesc]

Hi,

Thank you for your thoughts on how to reproduce. The mesh team has acknowledged this to be a bug. Hopefully it will get fixed for next nRF5 SDK for Mesh release.

Regards,
Terje