This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Thread error with large buffer
- To: "Trenton D. Adams" <tadams at extremeeng dot com>
- Subject: RE: [ECOS] Thread error with large buffer
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Fri, 20 Jul 2001 09:31:32 -0600 (MDT)
- Cc: eCos mailing list <ecos-discuss at sources dot redhat dot com>
- Organization: Red Hat, Inc.
On 20-Jul-2001 Trenton D. Adams wrote:
> >
> > On 20-Jul-2001 Trenton D. Adams wrote:
> > > > why not just make it static? also there are routines you can
> use
> > to
> > > > check the stack size and usage for a given thread. also you
> can
> > > adjust
> > > > the stack size for main (the default in a kernel i just
> glanced at
> > > is
> > > > 8k). also you can enable stack overflow checking.
> > > >
> > > > -Dan
> > > >
> > >
> > > This is a TEST program, I don't think it's really necessary to
> worry
> > > about silly things like where stuff resides in memory, whether
> it's on
> > > the stack or on the heap.
> >
> > Ah, but this is an embedded system, where you _do_ have to worry
> about
> > such things as "is my stack big enough for the buffer I just
> created?",
> > even for "test" programs.
> >
>
> Yes, stack size does matter, but caring whether it's on the stack or the
> heap is inconsequential.
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.