Add an assert o catch overflow of recursive mutex counter

[InnerSteff]

Fix add overflow check on recursive mutex counter

Description

There is no overflow check of the recursive mutex counter yet.
If the counter overflows, the mutex will be released on the next call of xQueueGiveMutexRecursive(),
even if the number of calls does not match the number of calls of xQueueTakeMutexRecursive().

This would lead to unpredictable behavior in the application.

Test Steps

call xQueueTakeMutexRecursive() more than the maximum value of UBaseType_t

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[aggarg]

Does this change attempt to catch infinite recursion of xQueueGiveMutexRecursive? Wouldn't an application result in stack overflow before that happens. Is this a theoretical fix or did you face any problem?

[InnerSteff]

This change attempt to catch an infinite call of xSemaphoreTakeRecursive().

It’s a theoretical bug fix I came across during design phase of my application when someone asked how often you can take a recursive mutex.

But, according to my understanding, it can not only occur in an infinite recursion scenario, but also if xSemaphoreTakeRecursive() is called in an infinite loop. Or in a loop with more iteration than the max value of UBaseType_t.
An (infinite) loop would not lead to a stack overflow.

[aggarg]

But, according to my understanding, it can not only occur in an infinite recursion scenario, but also if xSemaphoreTakeRecursive() is called in an infinite loop. Or in a loop with more iteration than the max value of UBaseType_t.
An (infinite) loop would not lead to a stack overflow.

Agree, but that would be a poorly written application. No sane application would do that. Asserts are there to help programmers to catch reasonable mistakes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[InnerSteff]

Thanks for picking up and merging my pull request, but may I ask what changed your mind to accept it?

[aggarg]

In our internal discussion, we realized that this check may help to catch a situation where somebody keeps taking a mutex but never gives it back.

Thank you for your contribution!