public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Greg Dyer" <gdyer@axys.com>
To: <ecos-discuss@ecos.sourceware.org>
Subject: [ECOS] Monitoring stack usage
Date: Wed, 06 Mar 2013 16:29:00 -0000	[thread overview]
Message-ID: <8A9A59002BD6CE4CBC872499112816E9011DACF5@msvr4.axys.tri.lan> (raw)

Hello,

I am running an embedded environment using multiple threads in eCos, a
main thread and a logging thread. I've been testing stack usages vs
different stack sizes in the logging thread because I had suspected that
a stack overflow could be occurring in the logging thread causing it to
lock up. I enabled CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT and started
printing the values from cyg_thread_measure_stack_usage as well as the
value from threadInfo.stack_used. 
The value from cyg_thread_measure_stack_usage and threadInfo.stack_used
are always identical. 

My testing:
Stack size of 4096 bytes. The usage got up to 3528 bytes (according to
cyg_thread_measure_stack_usage) 
Stack size of 10240 bytes. The usage got up to 3528 bytes (according to
cyg_thread_measure_stack_usage) 
Stack size of 20480 bytes. The usage got up to 5488 bytes (according to
cyg_thread_measure_stack_usage) 
I was hoping to see with the 10k stack size the usage growing above 4k.
In both the 4k and 10k stack sizes, the logging thread locked up. The
20k stack did not lock up.

I changed a few config parameters and ran the same code as the above
test (except for changing stack sizes) and found some strange results:
Stack size of 4096 bytes. The usage got up to 4096 bytes (according to
cyg_thread_measure_stack_usage) 
Stack size of 10240 bytes. The usage got up to 9820 bytes (according to
cyg_thread_measure_stack_usage) 
Stack size of 20480 bytes. The usage got up to 20208 bytes (according to
cyg_thread_measure_stack_usage) 
Stack size of 102400 bytes. The usage got up to 87350 bytes (according
to cyg_thread_measure_stack_usage) 
It seems that usage tracks fairly close to what the given stack size.
Only the 4k stack size locked up in this test.

Is there a reason that my stack usage could be growing so high in my
second test? The compiled code is identical, only some a few parameters
are changed in my running code. I was expecting to see my stack usage
possibly go above the 4k mark but not continue to grow with my stack
size. Is there a better way I can monitor stack usage to detect an
overflow so I can appropriately set a better stack size?

Thanks,
Greg

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

             reply	other threads:[~2013-03-06 16:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06 16:29 Greg Dyer [this message]
2013-03-06 22:26 ` [ECOS] " John Dallaway

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8A9A59002BD6CE4CBC872499112816E9011DACF5@msvr4.axys.tri.lan \
    --to=gdyer@axys.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).