Debugging stack overflow.

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderator: RoccoMarco

Post Reply
rew
Posts: 383
Joined: Sat Jul 19, 2014 12:59 pm
Has thanked: 2 times
Been thanked: 14 times

Debugging stack overflow.

Post by rew »

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.
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: Debugging stack overflow.

Post by Giovanni »

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
rew
Posts: 383
Joined: Sat Jul 19, 2014 12:59 pm
Has thanked: 2 times
Been thanked: 14 times

Re: Debugging stack overflow.

Post by rew »

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.
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: Debugging stack overflow.

Post by Giovanni »

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

Giovanni
rew
Posts: 383
Joined: Sat Jul 19, 2014 12:59 pm
Has thanked: 2 times
Been thanked: 14 times

Re: Debugging stack overflow.

Post by rew »

Ok. Found it....

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