Is the long gdb backtrace of FreeRTOS application a sign of stack overflow?

Question

I am using FreeRTOS for a project and I'm trying to debug it using gdb and JLinkGDBServer. My problem is that when I stop the execution and do a backtrace I just get line after line of:

#192 0x08005a88 in pxPortInitialiseStack (pxTopOfStack=0xa5a5a5a5, pxCode=0xa5a5a5a5, 
    pvParameters=0xa5a5a5a5)
    at /home/username/storage/repos/project/third_party/freertos/portable/GCC/ARM_CM3/port.c:231
#193 0x08005a88 in pxPortInitialiseStack (pxTopOfStack=0xa5a5a5a5, pxCode=0xa5a5a5a5, 
    pvParameters=0xa5a5a5a5)
    at /home/username/storage/repos/project/third_party/freertos/portable/GCC/ARM_CM3/port.c:231
#194 0x08005a88 in pxPortInitialiseStack (pxTopOfStack=0xa5a5a5a5, pxCode=0xa5a5a5a5, 
    pvParameters=0xa5a5a5a5)
    at /home/username/storage/repos/project/third_party/freertos/portable/GCC/ARM_CM3/port.c:231
#195 0x08005a88 in pxPortInitialiseStack (pxTopOfStack=0xa5a5a5a5, pxCode=0xa5a5a5a5, 
    pvParameters=0xa5a5a5a5)
    at /home/username/storage/repos/project/third_party/freertos/portable/GCC/ARM_CM3/port.c:231
#196 0x08005a88 in pxPortInitialiseStack (pxTopOfStack=0xa5a5a5a5, pxCode=0xa5a5a5a5, 
    pvParameters=0xa5a5a5a5)
    at /home/username/storage/repos/project/third_party/freertos/portable/GCC/ARM_CM3/port.c:231
#197 0x08005a88 in pxPortInitialiseStack (pxTopOfStack=0xa5a5a5a5, pxCode=0xa5a5a5a5, 
    pvParameters=0xa5a5a5a5)
    at /home/username/storage/repos/project/third_party/freertos/portable/GCC/ARM_CM3/port.c:231

Is this a sign of stack overflow or something? I am checking for stack overflow using configCHECK_FOR_STACK_OVERFLOW 2 in my FreeRTOSConfig.h

score 3 · Accepted Answer · answered Aug 16 '16 at 19:19

Yes - this is because GDB does not know when to stop unwinding the state. Or to put it another way, it does not know when it has reached the end of the stack frame for a task.

By default the end of a stack frame will leave the task in an error function, because you are not supposed to return from a task without deleting it, but the error function does not itself return anywhere. That is fine in most cases, with most debuggers, but sometimes GDB can be a little enthusiastic and the configTASK_RETURN_ADDRESS constant is provided to allow you to replace the address of the error function with a simple NULL - which GDB will not then try and unwind further.

For future reference, if you are wondering about a stack overflow, read the stack overflow detection pages on the FreeRTOS.org website: http://www.freertos.org/Stacks-and-stack-overflow-checking.html

score 2 · Answer 2 · answered Aug 16 '16 at 10:31

2

It turns out that adding #define configTASK_RETURN_ADDRESS 0 to FreeRTOSConfig.h solves the problem.

answered Aug 16 '16 at 10:31

evading

3,032
6
37
57

Is the long gdb backtrace of FreeRTOS application a sign of stack overflow?

2 Answers2