RE: [ECOS] Thread error with large buffer

RE: [ECOS] Thread error with large buffer

[Dan Conti]

4k is a lot of data to put on a stack. also note that you have 4000
bytes, not 4k there.

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

> -----Original Message-----
> From: Trenton D. Adams [ mailto:tadams@extremeeng.com ]
> Sent: Thursday, July 19, 2001 3:18 PM
> To: 'eCos mailing list'
> Subject: [ECOS] Thread error with large buffer
> 
> 
> I'm doing some network tests to test the things some of us 
> were talking
> about before with send sending everything before returning.  I get the
> output below.
> 
> Transfer rate: 656912 bits/sec, 306 bytes/write.
> TRACE: <4>[88]int main() This is the system-supplied default main()
> TRACE: <4>[107]void cyg_libc_invoke_main() main() has 
> returned with code
> 0. Calling exit()
> TRACE: <4>[84]void exit() Calling fflush( NULL )
> Start socket test
> ASSERT FAIL: <2>[166]static void 
> Cyg_Scheduler::unlock_inner() Bad next
> thread
> 
> 
> Below is the thread.  It doesn't give the error above if the buffer
> variable is 400.  Anyone have any ideas why this might be?  Surely a
> static buffer of 4K is not un-reasonable?
> net_test(cyg_addrword_t param)
> {
>     int s;
>     int one = 1;
>     int index;
>     struct sockaddr_in addr;
> 
>     char buffer[4000];
> 
>     buffer[0] = '\0';
> 
>     diag_printf("Start socket test\n");
>     init_all_network_interfaces();
> 
>     for (index = 0; index < 78; index++)
>     {
>         strcat (buffer, 
>             "Hello From eCos! Hello From eCos! Hello From eCos!\n");
>     }
> 
> 
>     s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
>     diag_printf("socket() = %d\n", s);
> 
>     diag_printf ("%x", inet_addr ("172.16.1.9"));
>     addr.sin_addr.s_addr = inet_addr ("172.16.1.9");
>     addr.sin_family = AF_INET;
>     addr.sin_port = htons (1024);
>     addr.sin_len = sizeof (addr);
>     if (connect (s, &addr, sizeof (addr)) != 0)
>     {
>         diag_printf ("Error connecting to socket! - %d\n", 
>             errno);
>         cyg_test_exit();
>     }
> 
>     if (send (s, buffer, strlen (buffer), 0) != 0)
>     {
>         diag_printf ("Error sending to socket! - %d\n", 
>             errno);
>         cyg_test_exit();
>     }
>         
> 
>     cyg_test_exit();
> }
> 
> Trenton D. Adams
> Embedded Developer
> Windows Developer
> Extreme Engineering Ltd.
> Calgary Alberta.
> 
> 
> 
> 

RE: [ECOS] Thread error with large buffer

[Trenton D. Adams]

  > -----Original Message-----
  > From: ecos-discuss-owner@sources.redhat.com [ mailto:ecos-discuss-
  > owner@sources.redhat.com] On Behalf Of Dan Conti
  > Sent: Thursday, July 19, 2001 5:00 PM
  > To: eCos mailing list
  > Subject: RE: [ECOS] Thread error with large buffer
  > 
  > 4k is a lot of data to put on a stack. also note that you have 4000
  > bytes, not 4k there.
  > 

If someone asked you the time, would you tell them 4:35 and 23 seconds?
If I didn't know that 4000 was not EXACTLY 4K, then I shouldn't be
programming let alone programming an embedded system.

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

RE: [ECOS] Thread error with large buffer

[Gary Thomas]

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.

RE: [ECOS] Thread error with large buffer

[Trenton D. Adams]

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

RE: [ECOS] Thread error with large buffer

[Gary Thomas]

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.

RE: [ECOS] Thread error with large buffer

[Trenton D. Adams]

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

RE: [ECOS] Thread error with large buffer

[Gary Thomas]

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"

RE: [ECOS] Thread error with large buffer

[Trenton D. Adams]

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

Is this just the way eCos does it?  Am I correct about other PC based
operating systems?

RE: [ECOS] Thread error with large buffer

[Gary Thomas]

On 20-Jul-2001 Trenton D. Adams wrote:
>   > >
>   > > 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"
> 
> Is this just the way eCos does it?  Am I correct about other PC based
> operating systems?

No - this is SOP everywhere, as far as I know it.

RE: [ECOS] Thread error with large buffer

[Trenton D. Adams]

  > 
  > On 19-Jul-2001 Trenton D. Adams wrote:
  > > Below is the thread.  It doesn't give the error above if the
buffer
  > > variable is 400.  Anyone have any ideas why this might be?  Surely
a
  > > static buffer of 4K is not un-reasonable?
  > 
  > It's not static - it's on the thread's stack.  You can make it
  > static (include the keyword) or make the thread stack larger.

When I said static I meant not dynamically allocated by me with malloc
or something.  Obviously it's not static since I didn't specify the
static keyword.

RE: [ECOS] Thread error with large buffer

[Gary Thomas]

On 19-Jul-2001 Trenton D. Adams wrote:
> Below is the thread.  It doesn't give the error above if the buffer
> variable is 400.  Anyone have any ideas why this might be?  Surely a
> static buffer of 4K is not un-reasonable?

It's not static - it's on the thread's stack.  You can make it
static (include the keyword) or make the thread stack larger.

[ECOS] Thread error with large buffer

[Trenton D. Adams]

I'm doing some network tests to test the things some of us were talking
about before with send sending everything before returning.  I get the
output below.

Transfer rate: 656912 bits/sec, 306 bytes/write.
TRACE: <4>[88]int main() This is the system-supplied default main()
TRACE: <4>[107]void cyg_libc_invoke_main() main() has returned with code
0. Calling exit()
TRACE: <4>[84]void exit() Calling fflush( NULL )
Start socket test
ASSERT FAIL: <2>[166]static void Cyg_Scheduler::unlock_inner() Bad next
thread


Below is the thread.  It doesn't give the error above if the buffer
variable is 400.  Anyone have any ideas why this might be?  Surely a
static buffer of 4K is not un-reasonable?
net_test(cyg_addrword_t param)
{
    int s;
    int one = 1;
    int index;
    struct sockaddr_in addr;

    char buffer[4000];

    buffer[0] = '\0';

    diag_printf("Start socket test\n");
    init_all_network_interfaces();

    for (index = 0; index < 78; index++)
    {
        strcat (buffer, 
            "Hello From eCos! Hello From eCos! Hello From eCos!\n");
    }


    s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    diag_printf("socket() = %d\n", s);

    diag_printf ("%x", inet_addr ("172.16.1.9"));
    addr.sin_addr.s_addr = inet_addr ("172.16.1.9");
    addr.sin_family = AF_INET;
    addr.sin_port = htons (1024);
    addr.sin_len = sizeof (addr);
    if (connect (s, &addr, sizeof (addr)) != 0)
    {
        diag_printf ("Error connecting to socket! - %d\n", 
            errno);
        cyg_test_exit();
    }

    if (send (s, buffer, strlen (buffer), 0) != 0)
    {
        diag_printf ("Error sending to socket! - %d\n", 
            errno);
        cyg_test_exit();
    }
        

    cyg_test_exit();
}

Trenton D. Adams
Embedded Developer
Windows Developer
Extreme Engineering Ltd.
Calgary Alberta.