How to measure the amount of stack used by a particular stack in an application of multitasking?

Hi Everyone,

I am currently experiencing an issue with System Crash. I do have multiple task running in RTOS and one of the Task is doing an overflow in the application and Could you please let me know, How to find the specific task consuming and overflowing the stack in RTOS.

Looking forward to hearing from you.

Thanks and Regards,
Santha Sai

Look a uxTaskGetSystemState(), vTaskGetInfo(), or uxTaskGetStackHighWaterMark2()

You probably also want to enable configCHECK_FOR_STACK_OVERFLOW

1 Like

You may also have luck with the vApplicationStackOverflowHook function. Given the parameters you may be able to simply print out the task handle of the offending task. This doesn’t always work though as the handle can be corrupted.

Other rudimentary strategies include increasing the stack size of the task which last had its stack size modified/task logic expanded or removing a suspected task from being created and running again.

This subject keeps on coming back. It is important because it can cost a lot of time when the source overflow can not be found.

I recently tried a demo project from mbedTLS, which declared:

#define MAX_REQUEST_SIZE  20000
...
int ssl_main( int argc, char *argv[] )
{
    unsigned char buf[MAX_REQUEST_SIZE + 1];
    /* Run the test. */
}

I took me a long time to see why after calling ssl_main() things started going wrong.
20,000 bytes had been written on a stack which was only 1K long.

PS. stack sizes are usually expressed as words, not as bytes. My stack was actually 1024 * 4 (4096) bytes long. The size of “a word” depends on the CPU.

Like @richard-damon, I am a big fan of using uxTaskGetSystemState() while developing and debugging. If it is possible, give plenty of stack space to all of your (suspect) tasks and measure how much is actually used.

And like Kody warned, vApplicationStackOverflowHook (configCHECK_FOR_STACK_OVERFLOW) may not always work as expected because the stack may be too much corrupted…