Stack at prvCheckTasksWaitingTermination()

Kernel
1

chaabanemalki wrote on Wednesday, October 14, 2015:

Hello,

I’m using FreeRTOS V8.0.0 with pic32MX.
When trying to delete few tasks. att some point the kernel gets stuck at prvCheckTasksWaitingTermination (), in the while loop
while( uxTasksDeleted > ( UBaseType_t ) 0U )
{
}
The variable xListIsEmpty keeps having 1 and apprently the kernel can’t delete a task.

my code is like the following
vTaskDelete(task1);
vTaskDelete(task2);
vTaskDelete(task3);
.
.

vTaskDelete(taskn);

Now i’m not sure in which task this problem is hapenning and this doesn’t happen all the time so it’s hard to catch it.

Any idea on what might be wronge in my code ? and how i track it when it happens ?

Thank you

2

heinbali01 wrote on Wednesday, October 14, 2015:

Hi Hicham

The following looks sounds like an easy victim for an optimising compiler:

    while( uxTasksDeleted > ( UBaseType_t ) 0U )
    {
    }

What if you replace it with the following:

    while( *( ( volatile UBaseType_t * ) &uxTasksDeleted ) > 0U )
    {
    }

Just to make sure that ‘uxTasksDeleted’ will be fetched again and again?

There is a second problem with such a loop: if the task performing the loop has the highest priority, no other task will be able to change te value of ‘uxTasksDeleted’.

Best regards.

3

rtel wrote on Wednesday, October 14, 2015:

This loop is actually FreeRTOS code, and the uxTasksDeleted variable is declared volatile, so should be fine. I’m pretty sure the ‘comprehensive’ build of the standard demo for this part continuously creates and deletes tasks, so the code is well exercised.

Do you have configASSERT() defined in your application? Also, which heap memory manager are you using?

4

heinbali01 wrote on Thursday, October 15, 2015:

This loop is actually FreeRTOS code, and the
uxTasksDeleted variable is declared volatile

I’m sorry, I should have dug a little deeper and find out (grep) where the code comes from :slight_smile:

5

chaabanemalki wrote on Thursday, October 15, 2015:

Yes, i’m using ConfigASSERT() and i’m using heap_4.c with vApplicationMallocFailedHook() defined aswell.

6

rtel wrote on Thursday, October 15, 2015:

Hmm. Not sure, is it possible the idle task is getting starved of processing time? (probably not, if the code you posted is running when you stop the debugger, as that is in the idle task).

I was thinking perhaps there was a corruption in the memory you were trying to free, but having configASSERT() defined is the best that can be done to detect that (I presume your assert function will halt execution, so you know if it gets called).

Other than that it could just be an old fashioned memory corruption somewhere. Can you stop the debugger when this issue occurs and step into through the code to see what it is doing - and why the task’s memory doesn’t get freed?