Should tasks stop executing when stack overflows?

Kernel
1

Is there any possibility that tasks executes even when a stack overflow happens?

2

It depends on what memory the overflow has corrupted. It may not lead to a crash or it may lead to a bug way after the overflow happened. The system can also work fine if the memory after the stack area happens to be unused. Basically, the system is not reliable after a stack overflowed and you should fix that.

3

I actually created 2 tasks, one a higher priority and another a lower priority. If I create the lower priority task first, the stack overflows but the execution don’t stop. But if higher priority is created first stack overflows , but the program crashes.

4

As I said, things you will observe after the memory has been corrupted by stack overflow will not be deterministic. So what you are observing is one of many possibilities. Please fix stack overflow by increasing the size of FreeRTOS task(s).

5

@aggarg wrote:

Please fix stack overflow by increasing the size of FreeRTOS task(s).

Indeed. Once you have assigned more stack space, your application should run without a problem. Nothing meaningful can be said about a stack overflow, except that you can expect random problems.

What you can do is define:

#define configUSE_STATS_FORMATTING_FUNCTIONS   1

and call uxTaskGetSystemState(). It will write the task status in an array of type ‘TaskStatus_t’ that you have allocated.

    UBaseType_t uxArraySize = uxTaskGetNumberOfTasks();

    // Allocate a TaskStatus_t structure for each task.  An array could be
    // allocated statically at compile time.
    pxTaskStatusArray = ( TaskStatus_t * ) pvPortMalloc( uxArraySize * sizeof( TaskStatus_t ) );

    if( pxTaskStatusArray != NULL )
    {
        // Generate raw status information about each task.
        configRUN_TIME_COUNTER_TYPE ulTotalRunTime;
        uxTaskGetSystemState( pxTaskStatusArray, uxArraySize, &( ulTotalRunTime ) );
    }

TaskStatus_t has many interesting fields, notably usStackHighWaterMark, which is commented as:

/* The minimum amount of stack space that has remained for the task since
 * the task was created.  The closer this value is to zero the closer the task
 * has come to overflowing its stack.
 */

In my projects I always start with a large stack space, and later on I will measure the actual space used. Then add some extra space of course. That process makes you more conscious of the actual amount of stack space used.

6

I have tried using usStackHighWaterMark API.

7

And, did it work as expected? When you assigned larger stacks, do you see the difference?