This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: eCos2 stack base corrupted?
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( ¤t->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,
-Rich
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss