OS_GetStackSpace, unexpected results

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • OS_GetStackSpace, unexpected results

    embOS 3.32e
    ARM (AT91RM9200)
    Lib SP

    I have some code in a low pri task that calls OS_GetStackSpace, cycling through a list of all tasks. After I exercize my program a bit, this test pops out an error saying that a specific task is down to 16 bytes of stack. This is surprising because the task is not being activated at all, it is always waiting on an OS event. Although the stack should have been more than enough, I tried adding a large amount to it and the error only changed to say that it was down to 20 bytes. Thinking that I might have a stray pointer writing into the stack area, I placed a large array in front of the task stack declaration and also one after it. Neither affected the error.

    In addition, the application continues to execute. I have linked with the stack checking library which should halt with an error if an actual stack overflow occured, but I am not seeing that.

    I am wondering if there is a known problem with OS_GetStackSpace. If not, does anyone have any suggestions on how I might go about tracking down the source of the problem ?

    George

  • Hello,

    embOS V3.32e is not the latest version, but there is no known problem with this version.

    Most likely a part of the stack is overwritten for some reason; maybe by an other task.

    This is how you can find out:
    - Start the program
    - Wait until the free stack space is reported to be low
    - stop the CPU
    - look at the memory

    You should see that the the stack memory has been overwritten.
    If this is repeatable, use a debugger (J-Link ?) to set a watchpoint on
    modification of this memory addr.
    Repeat the process above and see what modifies memory.

    Does this help ?
    What do you see on the stack (Should be filled with a character CD or AA or something) ?

    SHort feedback would be nice.

  • Thanks for taking the time to respond. The explanation that something else was overwriting the stack had eluded me since I had incorrectly guessed that the error would have moved when I put a pad in front and behind the stack space. As soon as I implemented a write breakpoint on that area I found the problem. I still don't understand exactly why the fault location did not change when I padded memory before and after the stack, but that is only a curiosity now.

    George

    The post was edited 1 time, last by gpontis ().