ta8086 wrote on Monday, September 15, 2014:
It seems there is a bug in queue.c/prvNotifyQueueSetContainer(). The line
configASSERT( pxQueueSetContainer->uxMessagesWaiting < pxQueueSetContainer->uxLength );
looks OK, but throws assert each time I try to add last queue element (when ASSERTs are enabled). Maybe the sign must be “<=” instead of “<”.
davedoors wrote on Monday, September 15, 2014:
I don’t know it looks right to me. The same test is in the if() statement below it. It is checking there is space in the queue before trying to write to it. If it was <= it would pass if the queue set way full but then still try to write to it.
qtdave wrote on Tuesday, November 03, 2015:
We have found the same issue, the assertion fails with pxQueueSetContainer->uxMessagesWaiting equal to pxQueueSetContainer->uxLength.
Looking at the call stack prvNotifyQueueSetContainer is called from xQueueGenericSend
We are running FreeRTOS V8.2.1
Anyone else found a similiar issue?
davidlcamlin wrote on Wednesday, March 29, 2017:
Have similar issue, set the queue to 160 elements, periodically call xQueueSendToBack and after a while it fails in the same configAssert, having pxQueueSetContainer->uxMessagesWaiting = pxQueueSetContainer->uxLength = 2. I’m using FreeRTOS 9.0.0 on ATSAME70Q21. This queue is added into a set using xQueueCreateSet(2), maybe is related?
rtel wrote on Wednesday, March 29, 2017:
The test in the assert is valid. As already pointed out in this thread, it is checking the line below it doesn’t fail, because if it did fail then the queue set would be in an inconsistent state.
When you are using a queue set you MUST ensure the number of spaces in the queue set is greater than or equal to the sum of all the spaces in the queues added to the set. If that is not the case then you can add something to a queue that is a set without the set ever knowing. That is what the assert is guarding against.
When you read from a queue set you MUST then also read from the queue. That is, if you read queue handle X from a queue set you MUST then read the item from queue X - again otherwise the queue set will be in an inconsistent state.
davidlcamlin wrote on Friday, April 07, 2017:
I created a set originally for 2 queues, one is receiving timer events (xQueueSendToBack) and the other from interrupt using xQueueSendToBackFromISR. Then when this thread waiting on xQueueSelectFromSet reports a message arrived in one of the queues, calls xQueueReceive on that queue immediately. I followed your suggestion and now the queue set is 3 (but no third queue added to the set). After about half a day of running, this assert is triggered again and pxQueueSetContainer->uxMessagesWaiting = pxQueueSetContainer->uxLength = 3. This thread doesn’t wait on anything else and processing of the message (on the 2nd queue) from ISR is light enough since was used in other projects without any problems. Am I doing something wrong? Maybe the timer (1st) queue isn’t processed quickly enough because the message from the 2nd queue is still being processed? But how is the set reporting 3 messages waiting when the third queue doesn’t exist in the set? Do I need to call anything after xQueueSelectFromSet?
davidlcamlin wrote on Friday, April 07, 2017:
I might have found the cause of the assert triggered, I needed to use combined length of first and second queue to xQueueCreateSet.