[ECOS] Stack error...

[ECOS] Stack error...

[Cristiano Ligieri Pereira]

I consistently getting this error in my application after it's running for
a while:

ASSERT FAIL: <4>[102]void Cyg_HardwareThread::check_stack() Stack base
corrupt

How could I corrupt the base of my stack? 

I'm using some debugging printf's within the kernel instead of TRACING
cause the TRACING messages are too big... Could it be a possible problem?

Thanks,
Cristiano.

PS: I'm running it using Linux-synthetic

------------------------------------------------------------
Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira

Re: [ECOS] Stack error...

[Jonathan Larmour]

Cristiano Ligieri Pereira wrote:
> 
> I consistently getting this error in my application after it's running for
> a while:
> 
> ASSERT FAIL: <4>[102]void Cyg_HardwareThread::check_stack() Stack base
> corrupt
> 
> How could I corrupt the base of my stack?

Something has scribbled over it. This generally means the stack has grown
until it's reached its limit at the bottom, indicating you either have
something looping accidentally, or need to increase your stack size.

> I'm using some debugging printf's within the kernel instead of TRACING
> cause the TRACING messages are too big... Could it be a possible problem?

printf() does kernel operations like lock mutexes and so on. If used from
_within_ the kernel I could easily imagine it causing you to fill up your
stack, due to effectively calling into itself again and again. Try
diag_printf() from <cyg/infra/diag.h> if you don't mind it being somewhat
simpler than standard printf().

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

Re: [ECOS] Stack error...

[Cristiano Ligieri Pereira]

It seems to be working fine with the diag_printf instead of printf. At
least it has been run for several hours already without any crash.

Thanks,
Cristiano.

> > I'm using some debugging printf's within the kernel instead of TRACING
> > cause the TRACING messages are too big... Could it be a possible problem?
> 
> printf() does kernel operations like lock mutexes and so on. If used from
> _within_ the kernel I could easily imagine it causing you to fill up your
> stack, due to effectively calling into itself again and again. Try
> diag_printf() from <cyg/infra/diag.h> if you don't mind it being somewhat
> simpler than standard printf().