RE: [ECOS] Thread error with large buffer

[Gary Thomas <gthomas at redhat dot com>]

On 20-Jul-2001 Trenton D. Adams wrote:
>   > 
>   > But you put it on the stack - that's the way you declared it to "C".
>   > Putting
>   > it on the heap can only be done explicitly, via malloc().
>   > 
>   > The point is, though, that we do need to be mindful of these things.
>   > Turning
>   > on stack checking code with asserts, as Dan recommended, is the way
> to
>   > find
>   > these little nits - eCos is an embedded system and for the most
> part,
>   > you
>   > have to protect yourself because it can't protect for you.
>   > 
>   > Note: on a system with full protection, such as Linux, you would
> have
>   > gotten
>   > an immediate failure when you tried to overextend your stack.  We
> simply
>   > can't
>   > provide that kind of protection on eCos (at least in the general
> case).
>   > Thus
>   > the ability to validate the stack, etc.
> 
> Yes, I do have ASSERTS/TRACING on, and that's the original reason I got
> the error in the first place.  Anyhow, my original point about this was
> that I don't care at the moment if I put it on the stack or heap.  As
> long as my stack is big enough, which it is now, I don't mind for my
> TEST program.
> 
> Isn't my buffer put on the heap if I decide to declare it static?  What
> about static and global?
> 
>>From what I've always understood, it is on the heap if it's static
> because otherwise it would be invalid after the thread was terminated
> since the stack gets deallocated.  static variables are always valid
> from the start of the program until the end.  Except for of course the
> scope of the variable is local to the thread so a pointer to it would
> have to be passed to the main program some way if I wanted to use it
> outside the thread.  No?

Actually, static variables are in a separate "area" - they simply exist
for the lifetime of your program, which in this case is as long as the
target is running that code.  Static variables are put somewhere out
there - it matters not where - but most importantly not on your stack.

The "heap" is actually for objects which have a lifetime less than
statics but greater than local [stack] objects.  You create something
on the heap using malloc() and destroy it using free().  If you were
writing in C++, you'd create them with the constructor 'new' which
in most cases calls malloc() "under the covers"