Re: Stack Overflow Detection

On Fri, 30 May 2008 10:37:20 -0500, Vladimir Vassilevsky
<antispam_bogus@xxxxxxxxxxx> wrote:



Richard Phillips wrote:
Hello all,

I'm thinking about implementing the above in a system I'm working on, does
anyone have a good strategy for doing this?

Look into the map file. A sensible linker will provide the call tree
with the corresponding stack usage. Depending on the system, you may or
may not need to account for the stack usage in the interrupts. Avoid the
unpredictable stack usage such as recursions and the dynamic allocations
from stack.

One possibility is having an area of RAM (beyond the stack "area") filled
with known data, if any of that data gets trashed then assume the stack has
overflowed. What are the pros and cons of this?

This is one of the common ways. The main problem with it is that you
never know for sure what is the maximum stack usage.

You CAN know the max stack usage if you can trace out every
possible call and interrupt (the call tree, as you mentioned). If it's
THAT important (in a "high reliability" application such as vehicle
control), the program can/should be planned and written from the start
with this in mind (doing as you said above, avoiding unpredictable
stack usage).

But this method, while rigorous, may not be easily applicable to "a
system I'm working on."


Another idea is to actually watch the SP, but one drawback is if I check
this at a predefined point in the code, then it's possible the worst case
scenario will occur between checks?

Check the SP in the interrupt which happens at random time instants.
This also doesn't guarantee the detection of the max. usage.

Make a repetitive interrupt that does nothing but check the stack.
If it happens often enough, it will have the largest size the stack
reaches. It would have to run quite often and may take a substantial
percentage of CPU cycles to catch the stack value as used in short
subroutines and interrupts, but it would reasonably find the max the
stack has reached (not neccesarily the theoretical max the stack could
get).

There's an old-fashioned device called a logic analyzer that when
properly set up can do wonders for tracing things such as stack usage
in real time without interfering with normal operation, but they don't
work with embedded parts that don't have address and data lines
brought out to pins. Some manufacturers have made versions of their
microcontrollers with all the pertinent lines bonded out, but I don't
know if anyone still does that.


Any better ideas?

Use the CPU with MMU. Limit the stack segment size.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

.

Relevant Pages

  • Re: Stack analyzer
    ... the depth of the entire stack over a whole program run. ... number of calls (and thus total stack usage) if the number of times the ... Then you might call the same event handler twice without being ... Fifth example: interrupt or signal handlers. ...
    (comp.programming)
  • Re: [PATCH] x86: unify x86 Makefile(s)
    ... max(stack usage foo(), stack usage bar). ... But gcc 3 didn't do that. ...
    (Linux-Kernel)
  • Re: Stack analyzer
    ... the depth of the entire stack over a whole program run. ... number of calls (and thus total stack usage) if the number of times the ... Then you might call the same event handler twice without being ... Fifth example: interrupt or signal handlers. ...
    (comp.programming)
  • Re: Problem with mlockall() and Threads: memory usage
    ... based on observed stack usage during running. ... It seems inconsistant that when using mlockallnewly malloced memory will ... >>stack would be a good compromise between latency and memory usage. ...
    (Linux-Kernel)
  • Re: Problem with mlockall() and Threads: memory usage
    ... based on observed stack usage during running. ... It seems inconsistant that when using mlockallnewly malloced memory will ... >>stack would be a good compromise between latency and memory usage. ...
    (Linux-Kernel)