Corrupt stack after task switch (Stac Smashing)

Hi FreeRTOS forum

I have a problem. From time to time I get stack smashing exception on my target. I still try to figure out why and how to getting the problem closer.
I get a stack smash exception and it is hit in task.c, function vTaskSwitchContext at taskEXIT_CRITICAL_ISR. (According to the call stack)

It seems to be related to the same task, but that is one of the things I try to be sure of. It does not happen very often, so it takes quit some time to debug.

I have added some code that stores the task switched out and in.
I got one where the in and out task where the same task and the top of the stack was NOT the same. I think that is very bad!!!
But questions remain: How can the top of stack in the TCB be different when a task is switched out and in again?

Im using a ESP32 module with ESP IDF v 4.4.3 and it uses FreeRTOS v 10.4.3

I dont think it is a FreeRTOS bug, but I could need some input on how this could happen and maybe how to debug the issue closer.


Have you checked for stack overflows (usual suspect #1)?


Yes i have. The overflow hook is used and it works. And it is not triggered.


The hook will not catch all cases reliably. You can manually check how much stack is used by scanning the stack memory for the free signature.

The next checks would be to ensure that your isr priority configuration is correct and no misuse of the xxxfromISR functions/ Maxsyscall priority stipulation takes place. Are you using a custom port or one from the standard code distribution?


Scanning the stacks for free signature, is that done with the water mark?

The ESP32 framework has there own port and I’m using that. They also have there own heap implementation. The ESP32 has 2 core’s so they handle that in a custom task.c also.
So yes, I use a custom port of the standard FreeRTOS


no, you need to do that manually, ie record beginning and end of stack when the task starts, and in the error case, look at the memory from beginning to end and see how far into the stack the memory free signature reaches. The reason is that if there is non initialized automatic memory in the task stack, the stack may be trashed without the overflow checker noticing it.

Since this is a custom port, make sure that the service (task switch) is has the lowest interrupt priority and that all interrups that use OS services run below MAX_SYSCALL priority and use only thos services that end in _FromISR.

If the custom port comes from the chip manufacturer, you should also contact them for support.


It seems forcing all tasks to one CPU core does the trick. It seems the chip manufacturer has some issues handling two cores in there custom port…


Thanks for letting us know! Are you in contact with the vendor?