ChibiOS Free Embedded RTOS

Posted: **Mon Mar 09, 2015 8:28 am**

Hi,

I seem to be having a stack overflow. I've increased some of my stacks to 1280 bytes from the original "one step up from 128" (=256). But still I'm getting stack overflows. Sometimes the stack trace from gdb shows me what thread I must be in. But this time...

Code: Select all

(gdb) where
#0  0x08002bd2 in port_halt ()
    at ../ChibiOS_2.6.6/os/ports/GCC/ARMCMx/chcore.c:48
#1  0x0800312a in chDbgPanic (msg=msg@entry=0x800b824 "stack overflow")
    at ../ChibiOS_2.6.6/os/kernel/src/chdebug.c:274
#2  0x0800340a in chSchDoRescheduleBehind ()
    at ../ChibiOS_2.6.6/os/kernel/src/chschd.c:315
#3  0x080034b8 in chSchDoReschedule ()
    at ../ChibiOS_2.6.6/os/kernel/src/chschd.c:370
#4  0x08002be8 in _port_switch_from_isr ()
    at ../ChibiOS_2.6.6/os/ports/GCC/ARMCMx/chcore_v6m.c:144
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

.... I get no functions that I wrote, so I don't know what the current thread is that is claimed to be out-of-stack.

Anyway, I did: print waLoggerThread and I get: somewhere in the middle:

Code: Select all

6148914691236517205 <repeats 74 times>,

... The number 6148914691236517205 is 0x555...55, which looks to me like a typical "initialization to find if the stack has been used". Last time, I increased the stack of the thread with the lowest number of "pristine" entries in its working area. Now I'm back again with a clear "stack overflow" inside my biggest thread, which also still has the highest number of pristine stack locations left....

Any suggestions?

Where is the main thread stack size set? For now I have put main to "sleep", and run what previously ran in main now in a separate thread where I can control the stack size.

Posted: **Mon Mar 09, 2015 9:22 am**

Hi,

Use the debug plugin in ChibiStudio, it will give you the unused stack size for each thread. In 3.0 the stack sizes are in the Makefile, in 2.6 in the .ld files.

Giovanni

Posted: **Mon Mar 09, 2015 10:33 am**

I don't have windows. The README tells me about c:\ ... and then I stop reading.

Isn't that plugin doing exactly the same as looking at those 0x55555's in the middle of the working area?

In my tracing where the check for the stack-overflow is, I came across the context switch hook:

Code: Select all

#if !defined(THREAD_CONTEXT_SWITCH_HOOK) || defined(__DOXYGEN__)
#define THREAD_CONTEXT_SWITCH_HOOK(ntp, otp) {                              \
  /* System halt code here.*/                                               \
}
#endif

The comment says: "system halt code here", which I think is not correct.

Posted: **Mon Mar 09, 2015 12:00 pm**

Yes, it is not correct, fixed it on repository.

Giovanni

Posted: **Mon Mar 09, 2015 9:57 pm**

Ok. Found it....

Due to an error, I was corrupting... the limit-for-the-stack-pointer....

ChibiOS Free Embedded RTOS

Debugging stack overflow.

Debugging stack overflow.

Re: Debugging stack overflow.

Re: Debugging stack overflow.

Re: Debugging stack overflow.

Re: Debugging stack overflow.