assert in xTaskRemoveFromEventList

yevpator75 wrote on Tuesday, July 09, 2019:

Hello
Under a stress test after about 10 min my programm fails in attempt to give semaphore

  test = 1;
    SemaphoreHandle_t x = xSemaphoreGive (gp_SenderInCountingSem);
    if (!x)
    {
        OS_PL_ASSERT(0);
    }
    test = 0;

xSemaphoreGive does not return 0, but gets stusk inside configASSERT IN this code in the xTaskRemoveFromEventList function:


BaseType_t xTaskRemoveFromEventList( const List_t * const pxEventList )
{
TCB_t *pxUnblockedTCB;
BaseType_t xReturn;

	/* THIS FUNCTION MUST BE CALLED FROM A CRITICAL SECTION.  It can also be
	called from a critical section within an ISR. */

	/* The event list is sorted in priority order, so the first in the list can
	be removed as it is known to be the highest priority.  Remove the TCB from
	the delayed list, and add it to the ready list.

	If an event is for a queue that is locked then this function will never
	get called - the lock count on the queue will get modified instead.  This
	means exclusive access to the event list is guaranteed here.

	This function assumes that a check has already been made to ensure that
	pxEventList is not empty. */
	pxUnblockedTCB = ( TCB_t * ) listGET_OWNER_OF_HEAD_ENTRY( pxEventList );
	configASSERT( pxUnblockedTCB );

Is there any idea how to troubleshoot this problem?
The FreeRTOS configuration is dynanmic, but I don’t actually use any malloc. The target is STM32F4.
I will be gratefull for any advice !

rtel wrote on Tuesday, July 09, 2019:

First thing to do is look through this list:
https://www.freertos.org/FAQHelp.html - starting with the requirements
for interrupt priorities on the Cortex-M, and the special requirements
to change the number of priority bits assigned to be preemption priority
on the STM32 (which is the only part I’m aware of that does not
automatically set all priority bits to preemption priority as opposed to
sub-priority).

yevpator75 wrote on Tuesday, July 09, 2019:

Thank you Richard for the prompt answer.

Actually, I already checked the interrupt priority and didn’t find any potential issue, but maybe Ishould have looked for something different. Could you please suggest what is some specific issue with priorities I should check?

Note again, sometimes my program survives under test (180 000 messages x 2 UART) and a dozen of tasks for 10 --15min . I read your article and tomorrow will increase the stack size of the task in which context the problem happens.

rtel wrote on Tuesday, July 09, 2019:

Actually, I already checked the interrupt priority and didn’t find any
potential issue, but maybe Ishould have looked for something different.
Could you please suggest what is some specific issue with priorities I
should check?

I can’t say anything more than is already comprehensively documented
here: https://www.freertos.org/RTOS-Cortex-M3-M4.html

If you are using one of the latest versions of FreeRTOS then the
additional assert messages will find most misconfiguration issues but
not all.

any news here? I’ve got a similar problem that I can reproduce really easily without having to wait…

Would you please describe your problem in a bit more detail? Are you also seeing as assert on the exact same line? Which hardware platform are you using? Have you tried all the steps mentioned here: https://www.freertos.org/FAQHelp.html

Also, would you please open a new issue.

Thanks.

Yes, I get stuck at the very same line. The event queue has an entry but there seems to be no owner…

I also opened a ticket of my own to describe my set-up(Stuck in configAssert of function xTaskRemoveFromEventList (tasks.c))…