Re: [ECOS] eCos2 stack base corrupted?

[Fredrik Hederstierna <fredrik at wespot dot com>]

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.

> 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.

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?

Best Regards,
/Fredrik Hederstierna


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