embedded software boot camp

Understanding Stack Overflow

Monday, June 4th, 2007 by Nigel Jones

I suspect that many, if not all bloggers are somewhat narcissistic. In my case it shows through in that I use one of the free services that keeps track of how many visitors I get and what brought them to this blog. Well, it turns out that many of the visitors to this blog get here not because of the brilliance of my writing, but because they did a Google search on “stack overflow” often qualified by PIC, or MSP430 etc. For many of these visitors I suspect they leave empty handed. Thus in an attempt to make these visits less pointless, let me give you my take on what causes a stack overflow in an embedded system.

First of all, go read the Wikipedia description of stack overflow. There’s nothing wrong with the description – it’s just incomplete from an embedded systems perspective.

If you are having problems with 8 bit PICs, then you should read this. For other architectures, read on…

On the assumption that you are getting a stack overflow and that you aren’t performing recursion or attempting to allocate a large amount of storage on the stack, what can be going wrong? Here’s a check list.

  1. What’s your stack size set to? If you don’t understand the question then you need an introductory course to embedded systems programming. If you do understand the question – but don’t know the answer – then this is the most likely source of your problem. How can this be you ask? Well, most embedded systems compilers are designed to work with a particular family of processors. The low end of the family may have a tiny amount of memory (e.g. 128 bytes). As such setting the default stack size to 16 bytes may be a sensible thing to do. Thus, your first step is to ensure that the stack size is set to something reasonable for your system. Click here for advice on how to do this.
  2. Which stack is overflowing? Many processors / compilers support / implement multiple stacks. A typical dichotomy is a call stack (upon which the return addresses of functions are stored) and a data or parameter stack (upon which automatic variables are stored). If you are using an RTOS, then typically there will be a shared call stack while each thread will have its own data stack. Thus is it the shared call stack that is overflowing, or is it the parameter stack associated with a particular task? Once you’ve made the determination which stack is overflowing then finding out exactly what gets placed on that stack will help lead you to the solution to your problem. If you can see no obvious high level language construct that is causing the problem, then the single most likely cause of your misery is an interrupt service routine…
  3. An interrupt service routine can use up an extraordinary amount of space on the stack. For a discussion of how this arises and its impact on performance, see this article. This problem is compounded if your system allows interrupts to be nested (that is, it allows an ISR to itself be interrupted).
  4. Certain library functions (printf() and its brethren are prime offenders) can use an enormous amount of stack space.
  5. If you are writing partially in assembly language, are you failing to pop every register that you pushed? This often occurs if you have more than one exit point from a function or ISR.
  6. If you are writing entirely in assembly language, did you set up the stack pointer correctly and do you know which way the stack grows?
  7. Have you made the mistake of programming a microcontroller that you don’t understand? For example, low end PIC processors have a tiny call stack which is easily overflowed. If you are programming a PIC and don’t know about this limitation, then quite frankly, I’m not surprised you are having problems.
  8. If none of the above solve your problem, then I’m afraid you are most likely in to a stack over-write problem. That is, a pointer is being de-referenced that results in the stack being overwritten. This can often arise when you allocate an array on the stack and then access an element beyond the end of the array. Lint will find a lot of these problems for you. If you don’t know what Lint is, see this article. If you do know what Lint is and aren’t using it then you deserve to be faced with these sorts of problems.

I have also written a related article on setting your stack size that you may find useful.

Home

6 Responses to “Understanding Stack Overflow”

  1. Karl says:

    Thanks for the information. I was getting the problem cause I had too many scripts on my blog template.I had my html code confusing and plenty of errors. If it is a webpage I suggest they use htmltidy free tool to clean the junk code.

  2. Esther says:

    If you get ‘stack overflow error’ message, try a registry cleaner to scan your PC, fix registry error.Download some registry cleaners on http://www.pcerrorsfixer.com . I think regweep is good. I bought this software last month, now my pc not receive any errors message again.

  3. Balaji Mahadev says:

    Well i disagree, your wiritng skills are commendable…simple language conveying the message, what else do the engineering folk need. I never knew you had a blog and i always use your top ten questions to interview members into my team… surprising that after all these years of it being published, i hardly get anyone who can answer all….

  4. Nigel Jones says:

    Thanks for the kind words. It's interesting that you didn't know about this blog. My readership is dominated by readers from the USA & Western Europe. Although I get a number of visitors from India / China / Japan, they are nearly all via a search engine – and very few of them come back (in contrast to the USA / Europe). Hopefully you are the start of a trend!

  5. Nigel Jones says:

    As a further note, for those of you that don’t know what Balaji Mahadev is referring to about the ‘top ten questions’. A number of years ago I wrote an article for Embedded Systems Programming magazine entitled ‘A ‘C ’Test: The 0x10 Best Questions for Would-be Embedded Programmers’. The test has since been copied and reproduced all over the web. Indeed I still get correspondence on it. An updated version of the test suitable for your own customization is available at my web site. The original is also available here.

  6. Willaim says:

    Some fruits of my labor

    a way to watch your stack and find some of those mysterious problems on the MSP430
    sometime we are all careless when programming
    then you get one of those weird errors that overwrite a variable close to the stack what a PITA
    this should at least help to find out when your stack overflows or perhaps when something else writes into the stack space.

    #include string.h // C string functions

    unsigned int StackWatch(unsigned char fill);
    unsigned char StackIntact(unsigned char CHRS)

    const char stackstr[]=”#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=”;

    #pragma DATA_SECTION (_stackTAIL, “.stack”);//locate this variable at the stacks end (lowest address)
    const char _stackTAIL;//don’t futz with this variable //DANGEROUS
    unsigned int stacktail=0;
    unsigned int StackWatch(unsigned char fill)
    {
    if (stacktail==0)
    {
    stacktail=(unsigned int)&_stackTAIL; //debugging
    strncpy((void *)stacktail ,stackstr,fill);
    }
    if(fill==0)stacktail=0;//discard the pointer
    return stacktail;
    }

    unsigned char StackIntact(unsigned char CHRS)
    {
    if (stacktail==0)return 0;

    if (CHRS>strlen(stackstr))CHRS=strlen(stackstr);
    return strncmp((void *)stacktail, stackstr, CHRS);

    }

    ////USE IT LIKE THIS>>
    //in main only once..

    //StackWatch(20); ///Make sure you have enough chars in the stackstr const…

    //in a loop somewhere>>

    //if(StackIntact(20))
    //.ERROR CONDITION.//blink led or something..

    //if it doesn’t ==0 then the stack is not intact for that many characters

    //////////////
    //WHEN YOU ARE DONE WITH IT>>
    //StackWatch(0);//discards the pointer to the end of the stack

    I don’t know that i’d leave it in production code but it really comes in handy for Debug code
    maybe…It would probably come in handy to reset if something went awry but i think it would just happen again so really pointless in production quality code
    yes, you can do this through CCS and whatnot but thats a PIA

Leave a Reply