Re: [ECOS] Error on Cyg_Counter::add_alarm

Re: [ECOS] Error on Cyg_Counter::add_alarm

[Anthony Tonizzo]

Matt:

>I had some problems with alarms several months ago in
>the FreeBSD stack, but I can't remember the details. 

Fortunately it turns out to have been a very simple
mistake. The stack space allocated for the process was
too small, and when the second task kicked in, it was
probably overwriting the stack of the first. I still wonder
how I got away with this for so long, but once it was
increased to a much bigger size all issues disappeared.

Which brings up an interesting subject, which I am sure
can be of interest to many, especially those working in
somewhat "restricted spaces":

How do you estimate the amount of stack space needed for
a given task? 

I can estimate what _my_own_ stack requirements are, but 
how much more do I have to plan for the "ecos" stuff? When 
I ran these tasks I assumed that 8K were going to suffice,
but evidently that was not the case. Now, bitten once, I
jacked up the size to 32K, but that is probably an overkill,
and I can get away with it because my system has several
megabytes of memory. 

But besides the fact that having a lot of memory doesn't
mean that you have to throw it away, a lot of folks out 
there do not have this luxury and have to make much more
reasoned assessments.

Is there a rule of thumb that the "gurus" out there use?

Thanks
Tony


____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

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

Re: [ECOS] Error on Cyg_Counter::add_alarm

[Nick Garnett]

"Anthony Tonizzo" <atonizzo@lycos.com> writes:

> I can estimate what _my_own_ stack requirements are, but 
> how much more do I have to plan for the "ecos" stuff? When 
> I ran these tasks I assumed that 8K were going to suffice,
> but evidently that was not the case. Now, bitten once, I
> jacked up the size to 32K, but that is probably an overkill,
> and I can get away with it because my system has several
> megabytes of memory. 

The eCos HALs define the values CYGNUM_HAL_STACK_SIZE_MINIMUM and
CYGNUM_HAL_STACK_SIZE_TYPICAL for defining stack sizes. The MINIMUM
value is essentially the OS overhead plus a little to allow a simple
thread to run. The TYPICAL value provides enough space for several
call levels and more local variables -- it is mostly used by the test
programs to define stacks. Both these values tend to be somewhat
generous, but MINIMUM tends to be around 1k while TYPICAL tends to be
around 2k.

Your 8k stack ought to be more than adeqate, unless you have turned
off the interrupt stack and have some very deep interrupt nesting. It
is probably worth investigating exactly what is causing so much stack
to be used.

If you enable assertions (always a good idea during development) you
will also enable stack checking. Rerunning with the 8k stacks ought to
provoke an error. With a breakpoint in cyg_assert_fail() you ought to
then be able to do a backtrace and see what is being called. 


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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

Re: [ECOS] Error on Cyg_Counter::add_alarm

[Nick Garnett]

"Anthony Tonizzo" <atonizzo@lycos.com> writes:

> > If you enable assertions (always a good idea during
> > development) you will also enable stack checking. 
> 
> I did not have assertions enabled, and I should
> have known better.
> 
> But after enabling the traces and providing my own 
> cyg_assert_fail() I noticed that, with the stack back
> at 8K, the assertion comes immediately at the start of
> the DHCP process (network stack).
> 
> So, the 8K might be plenty for a run-of-the-mill thread,
> but as soon as you begin adding things such as an entire
> network stack, things get ugly pretty quickly.

This still doesn't sound right. Which thread is actually overflowing?
While TYPICAL may be a bit too small for network client stacks, 8k
ought to be more than enough. The internal TCP/IP stack threads should
also be correctly sized.

Maybe something has happened to the DHCP code to cause it to allocate
large arrays or something on the stack. Or maybe there is a problem
with the way that the DHCP thread is being created.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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

Re: [ECOS] Error on Cyg_Counter::add_alarm

[Anthony Tonizzo]

> If you enable assertions (always a good idea during
> development) you will also enable stack checking. 

I did not have assertions enabled, and I should
have known better.

But after enabling the traces and providing my own 
cyg_assert_fail() I noticed that, with the stack back
at 8K, the assertion comes immediately at the start of
the DHCP process (network stack).

So, the 8K might be plenty for a run-of-the-mill thread,
but as soon as you begin adding things such as an entire
network stack, things get ugly pretty quickly.

The only course of action now it to raise the stack space
until the assertions disappear, and then, as Arkadi
recommended, give it some slack.

Thanks
Tony


____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

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

Re: [ECOS] Error on Cyg_Counter::add_alarm

[Andrew Lunn]

On Mon, May 24, 2004 at 09:13:11AM +1000, Arkadi Grosman wrote:
> I do not think there is a "rule of thumb". There is a crude way of founding
> out how much stack you need:
> In your development system ( it would typically have way more memory
> installed compared to production one )  allocate as much as you can for
> stacks and fill the stack mem space with some pattern ( eg AA55 ). Run the
> system under stress and see how much of "patterned" stack space was
> overwritten for every task. Set your production system stacks to these sizes
> plus some slack 

eCos already have code to do this for you. Take a look at
CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT
        
        Andrew

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

RE: [ECOS] Error on Cyg_Counter::add_alarm

[Arkadi Grosman]

I do not think there is a "rule of thumb". There is a crude way of founding
out how much stack you need:
In your development system ( it would typically have way more memory
installed compared to production one )  allocate as much as you can for
stacks and fill the stack mem space with some pattern ( eg AA55 ). Run the
system under stress and see how much of "patterned" stack space was
overwritten for every task. Set your production system stacks to these sizes
plus some slack 

Cheers
Ark

----Original Message-----
From: Anthony Tonizzo [mailto:atonizzo@lycos.com]
Sent: Monday, 24 May 2004 06:04
To: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Error on Cyg_Counter::add_alarm


Matt:

>I had some problems with alarms several months ago in
>the FreeBSD stack, but I can't remember the details. 

Fortunately it turns out to have been a very simple
mistake. The stack space allocated for the process was
too small, and when the second task kicked in, it was
probably overwriting the stack of the first. I still wonder
how I got away with this for so long, but once it was
increased to a much bigger size all issues disappeared.

Which brings up an interesting subject, which I am sure
can be of interest to many, especially those working in
somewhat "restricted spaces":

How do you estimate the amount of stack space needed for
a given task? 

I can estimate what _my_own_ stack requirements are, but 
how much more do I have to plan for the "ecos" stuff? When 
I ran these tasks I assumed that 8K were going to suffice,
but evidently that was not the case. Now, bitten once, I
jacked up the size to 32K, but that is probably an overkill,
and I can get away with it because my system has several
megabytes of memory. 

But besides the fact that having a lot of memory doesn't
mean that you have to throw it away, a lot of folks out 
there do not have this luxury and have to make much more
reasoned assessments.

Is there a rule of thumb that the "gurus" out there use?

Thanks
Tony


____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp
?SRC=lycos10

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

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

Re: [ECOS] Error on Cyg_Counter::add_alarm

[Matt Jerdonek]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1854 bytes --]

This is a complete guess but ...

I had some problems with alarms several months ago in
the FreeBSD stack, but I can't remember the details. 
I noticed that Andrew Lunn fixed a linked list issue
in net/bsd_tcpip/current/src/ecos/timeout.c after 2.0
was released.  I updated to the tip version of the
bsd_tcpip package and got better results.

Good luck,
-- Matt


--- Anthony Tonizzo <atonizzo@lycos.com> wrote:
> Hi:
> 
> I am running into a problem with a small application
> I am
> running and was wondering if there is someone out
> there
> that has stumbled on this before and can share some
> experience.
> 
> The application is running on an MBX board and it is
> very simple. I have two threads, both of which work
> just
> fine when run independently.
> 
> They both use the ethernet interface, so the first
> thread
> calls init_all_network_interfaces() and I use a 
> cyg_flag_wait() to wake up the second when the
> ethernet 
> is up.
> 
> Everything works fine until I open a socket for the
> second
> thread. As soon as the first couple of packets have
> been
> sent back and forth, I get this message from gdb:
> 
> Program received signal SIGTRAP, Trace/breakpoint
> trap.
> 0x00055214 in Cyg_Counter::add_alarm(Cyg_Alarm*) (
> this=0x2330300d,alarm=0xC2630)
> at
>
/ecos-d/Cygwin/opt/ecos/ecos-2.0/packages/kernel/v2_0/src/common/clock.cxx:290
> 
> I have read documentation and browsed the newsgroups
> with little success. Any idea where I should start
> to try 
> to figure out what is going on?
> 
> Thanks
> Tony
> 
> 
> 
> 


	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

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

[ECOS] Error on Cyg_Counter::add_alarm

[Anthony Tonizzo]

Hi:

I am running into a problem with a small application I am
running and was wondering if there is someone out there
that has stumbled on this before and can share some
experience.

The application is running on an MBX board and it is
very simple. I have two threads, both of which work just
fine when run independently.

They both use the ethernet interface, so the first thread
calls init_all_network_interfaces() and I use a 
cyg_flag_wait() to wake up the second when the ethernet 
is up.

Everything works fine until I open a socket for the second
thread. As soon as the first couple of packets have been
sent back and forth, I get this message from gdb:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00055214 in Cyg_Counter::add_alarm(Cyg_Alarm*) ( this=0x2330300d,alarm=0xC2630)
at /ecos-d/Cygwin/opt/ecos/ecos-2.0/packages/kernel/v2_0/src/common/clock.cxx:290

I have read documentation and browsed the newsgroups
with little success. Any idea where I should start to try 
to figure out what is going on?

Thanks
Tony



____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

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