detecting stack overflow

Hi,

Our software crashed after adding some new functions. I suspect there may be a chance of stack overflow.

Could any expert offer some advice as to how to ascertain whether there is a stack overflow, better still what's the best way to isolate where in the code that happens?

We are using ARM9 chipset. Is there any built-in functionalities to capture this?

Thanks

Reply to
Daniel
Loading thread data ...

Why not fill an area of RAM above the top of the stack with a known code like 0xDEADBEEF or similar. Run your program until the crash and then inspect the memory. If your pattern has been overwritten then Bob's your uncle.

Reply to
Tom Lucas

"Tom Lucas" wrote in message news: snipped-for-privacy@despina.uk.clara.net...

Also set a breakpoint to trigger when the first location is written (or the range if your debgger can do so) and then look back through the call history to see where you were when the stack flowed over.

Reply to
Tom Lucas

Reply to
Daniel

In that case do it for every stack, then when it crashes inspect every stack and you will see which one has overflowed.

Alternatives:

  • Add code to the scheduler that checks the stack use for you calling an error function when the task it is running goes over its stack.
  • If you are getting an abort on your ARM9, then place a break point in the abort, and from there inspect which task was currently running, or look at the address at which the abort occurred and try to determine it from there.

Regards, Richard.

  • formatting link
  • formatting link
    for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
Reply to
FreeRTOS.org

Look into the *.map file and see what is the maximum stack usage. You may also have to add the stack used by the interrupts to it.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

You should always check stack usage for every task at any rate. The

0xDEADBEEF method works well, or filling with zeros.

Every serious project that I've worked on has had a task stack overhead checker. If the OS didn't come with one, we put one in.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

ARM9 ... do you have an MMU and an OS that supports it ?

If so, then you could consider the big iron method of letting the MMU manage memory area for each stack. If a task goes outside the allocated range you get an exception. To that you can either register an error with all the details, or throw another 8K at it.

Reply to
George Pontis

Have the system check the stack usage of each stack. And output it periodically. See who is running low.

Reply to
Neil

Just a general technique, probably applicable to multiple stacks: I clear the stack to 0, and define a small section (a byte or three) at the end of the stack as no-man's land. My regular heartbeat interrupt checks this is still clear. If not, abandon ship noisily.

Steve

formatting link

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.