[ECOS] eCos2 stack base corrupted?

NavEcos ecos@navosha.com
Fri Jan 3 11:01:00 GMT 2003

On Friday 03 January 2003 10:20 am, Fredrik Hederstierna wrote:
> Thanks for trying to help me, see comments below
> NavEcos wrote:
> > Did you increase your stack size ?
> I have done this, but same problem occures event with 1MB stack. We dont
> use any recursive functions either, if eCos does this I dont know.

Can you tell me what functions you are using in this thread?  If it's the 
network (TCP/IP) stack I can confirm that I've run into similar problems when 
I was intentionally taxing the TCP/IP stack.

> > You can enable stack checking as well in eCos
> I have done this, otherwise I wouldnt get this ASSERT.static.
> Its the stack _base_address_ (a member variable in the hardware thread
> struct) that is trashed, not stack overflow that is the problem I believe.
> I do not know if the threads are allocated at consecutive memory with the
> stacks, I guess thread-structs are in the '.data' segment and the actual
> stacks in the '.bss' section.

Well, when you create a thread you specify a variable that is used for that 
stack (usually an array of characters), you might want to see what other 
variables are declared around the stack variable...

You can get a list of all your symbols in the order of where they are place in 
your program with:

readelf -s YOUR_ECOS_EXECUTABLE | sort +1

NOTE: if you've declared your symbols "static" I am not sure it will work

And REMEMBER: stacks grow DOWN, not up.  So you usually start from the end of 
your array, and work backward.

> I seems like its just in the context-switch the crash occurs, when the
> thread the scheduler wants to run got  bad stack address.
> I found a thing I wonder about in the scheduler-code:
> In void Cyg_Scheduler::unlock_inner( cyg_ucount32 new_lock )
>                // Switch contexts
>               HAL_THREAD_SWITCH_CONTEXT( &current->stack_ptr,
> &next->stack_ptr );
>                // Worry here about possible compiler
>                 // optimizations across the above call that may try to
>                 // propogate common subexpresions.  We would end up
>                 // with the expression from one thread in its
>                 // successor. This is only a worry if we do not save
>                 // and restore the complete register set. We need a
>                 // way of marking functions that return into a
>                 // different context. A temporary fix would be to
>                 // disable CSE (-fdisable-cse) in the compiler.
> Can this be a problem?

Honestly: I'm too ignorant to address this question.

Have you modified any internals of eCos?  If you HAVE: The C++ classes have to 
match the C structures, other people have run into that problem I know.

Also, be certain that if you compiled eCos and your application with the SAME 
level of optimization, I have heard there are possible problems with, for 
example, compiling eCos with -O2 and your application with -O1 but I have not 
confirmed it.

> Best Regards,
> /Fredrik Hederstierna

Hope it helps,

Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

More information about the Ecos-discuss mailing list