I’m having an issue with a 3rd party library that makes extensive use of binary semaphores. The symptoms point to some sort of deadlock, but I am not having any luck figuring out exactly what’s going on.
Is there a mechanism in FreeRTOS for monitoring which tasks are holding or waiting on a binary semaphore?
I can add them to the registry with vQueueAddToRegistry, but I’m not clear on where to go from there. I’m looking for something like vQueueGetMutexInfo that also works on semaphores.
Other suggestions for what to monitor while debugging to get to the bottom of this are also appreciated.
Semaphores do NOT have a “owner” as there is no requirement that the task that takes the semaphore be the task that later gives it.
You can see who is waiting on which semaphores, and vQueueAddtoRegistry lets you put a name on each semaphore, but you would need to figure out who was supposed to give each of them.
You could use the TRACE macros to record the various takes and gives to give you a history of what has happened recently.
If they are using semaphores as Mutexes, you could try changing them to Mutexes, and then you could see who took but didn’t give back a given semaphore.
You could use the TRACE macros to record the various takes and gives to give you a history of what has happened recently.
If they are using semaphores as Mutexes, you could try changing them to Mutexes, and then you could see who took but didn’t give back a given semaphore.
Thanks, I’ll give this both of these a shot as well. I’m pretty sure they are using them as mutexes, so that should work
The tasks waiting will be on the xTaskWaitingToReceive list in the Semaphore, which might be available with a good Kernel aware debugger, or you can just manually examine the list in the Semaphore.
So if I’m looking at the xQueueRegistry, it will be xQueueRegistry[x].xHandle->TasksWaitingToReceive and if uxNumberOfItems > 0 then there are tasks waiting on this semaphore?