Monday, May 21st 2018, 11:10am UTC+2

You are not logged in.

  • Login
  • Register

gpontis

Beginner

Date of registration: Dec 18th 2007

Posts: 44

Location: California

1

Tuesday, December 18th 2007, 6:26pm

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

MikeQ

Beginner

Date of registration: Dec 3rd 2007

Posts: 16

2

Tuesday, December 18th 2007, 9:52pm

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.

gpontis

Beginner

Date of registration: Dec 18th 2007

Posts: 44

Location: California

3

Wednesday, December 19th 2007, 7:01am

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

This post has been edited 1 times, last edit by "gpontis" (Dec 19th 2007, 7:18am)


Similar threads