[En-Nut-Discussion] Can a thread determine its stack space?

[Henrik Maier]

Thank you Ulrich for implementing NUTDEBUG_CHECK_STACK as a proper nutconf
option. 
I agree that this is the proper way of doing it and is a very useful
feature. In particular as the performance overhead is very small and affects
only the creation of threads.

Henrik

> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of uprinz2 at netscape.net
> Sent: Friday, 24 September 2010 4:55 PM
> To: en-nut-discussion at egnite.de
> Subject: Re: [En-Nut-Discussion] Can a thread determine its stack
> space?
> 
> Hi Henrik!
> 
> 
> Yes I know how to quick and dirty throw in a define. But my intention
> was to make it nice and avoid my questions to be asked again by others.
> 
> 
> 
> I modified nutconf to set NUTDEBUG_CHECK_STACK in cfg/os.h
> I ensured that #include <cfg/os.h> exists in all files regarding stack
> / thread handling.
> 
> 
> If you then recompile, with or without OS-Debug set, the mechanism ist
> actiavted to get the full ammount of stack 'never touched'.
> 
> 
> If NUTDEBUG_CHECK_STACK is not set the reply must be 0x20 or 32 as only
> 32 bytes are preset with 0xdeadbeef. If the reply is less than 32 the
> stack already scrateched the lower 32 bytes and you should think about
> giving your thread some more space to live.
> 
> 
> With this solution you have all options using nutconf or your own
> modified Makefiles.
> 
> 
> While lot of people use Nut/OS for their tasks and live with a dirty
> hack here and there, there must be some people who try to keep the
> things in a row.
> So I try to be one of these guys who keep Nut/OS useable for newbies as
> well as for the old aces.
> 
> 
> So thanks to you guys for giving me the right hints. I will extract
> that patch from the STM32 branch and put it into trunk in the nex few
> days.
> If there is something else you might like to see in thread / context
> handling, give me a note.
> 
> 
> Best regards
> Ulrich
> 
> 
> -----Original Message-----
> From: Henrik Maier <hmnews at proconx.com>
> To: 'Ethernut User Chat (English)' <en-nut-discussion at egnite.de>
> Sent: Fri, Sep 24, 2010 4:50 am
> Subject: Re: [En-Nut-Discussion] Can a thread determine its stack
> space?
> 
> 
> The crucial file is context.c. This needs to be recompiled with
> NUTDEBUG_CHECK_STACK set. Then the stack is filled with the pattern.
> Otherwise only the bottom has the DEADBEEF pattern hence StackAvail
> only
> returns a constant small amount left.
> 
> NUTDEBUG_CHECK_STACK is only used in two places: context.c and
> thread.c.
> 
> You should be able to add -DNUTDEBUG_CHECK_STACK to your compilation
> script
> using userconf.mk or some other mechanism. Or just use brute force and
> add a
> #define NUTDEBUG_CHECK_STACK to those two source files.
> 
> Henrik
> 
> > -----Original Message-----
> > From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> > bounces at egnite.de] On Behalf Of uprinz2 at netscape.net
> > Sent: Thursday, 23 September 2010 5:40 PM
> > To: en-nut-discussion at egnite.de
> > Subject: Re: [En-Nut-Discussion] Can a thread determine its stack
> > space?
> >
> > Hi Henrik,
> >
> >
> > I found these defines but expected them to exist as a nutconf option
> or
> > at least as a prepared
> > //  #define NUTDEBUG_USE_ASSERT
> >
> > But ok, what I wanted was this:
> > stack_avail = (uint32_t)((uptr_t) tdp->td_sp - (uptr_t) tdp-
> >td_memory)
> >
> >
> > The advance of static size_t StackAvail(NUTTHREADINFO *td) if the
> above
> > define is enabled is, that it checks the lowest stack size until its
> > call by tracing for the 0xDEADBEEF pattern.
> >
> >
> > Hmmm, it doesn't work...
> >
> >
> > Here it comes:
> > Most of the source files do not include osdebug.h nor nutdebug.h so
> > defining this NUTDEBUG_CHECK_STACK doesn't have any effect.
> > osdebug.h doesn't include nutdebug.h so some simple checking and
> > breaking / asserting isn't possible.
> >
> >
> > That's the reason why NUTDEBUG_CHECK_STACK enabled in one file at my
> > place leads to just returning 20 bytes free for all threads. This
> > doesn't change even if I set the threaads stack x3 or x4.
> >
> >
> > I'll think this has to be reworked a bit.
> >
> >
> > But thanks for pushing me into the right direction, Henrik
> >
> >
> > Best regards
> > Ulrich
> >
> >
> >
> >
> > -----Original Message-----
> > From: Henrik Maier <hmnews at proconx.com>
> > To: 'Ethernut User Chat (English)' <en-nut-discussion at egnite.de>
> > Sent: Thu, Sep 23, 2010 1:51 am
> > Subject: Re: [En-Nut-Discussion] Can a thread determine its stack
> > space?
> >
> >
> > Hi Ulrich,
> >
> > If you enable just NUTDEBUG_CHECK_STACK during system build,
> > NutThreadStackAvailable() tells you how much unused stack is
> available
> > for a
> > given thread.
> >
> > This is done using a pattern check for the DEADBEEF pattern. This has
> > no
> > other performance or code impact to a system than that the stack is
> > filled
> > with a pattern upon creation in NutThreadCreate().
> >
> > Refer to context.c and thread.c source code.
> >
> > Henrik
> >
> >
> > > -----Original Message-----
> > > From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-
> discussion-
> > > bounces at egnite.de] On Behalf Of Ulrich Prinz
> > > Sent: Thursday, 23 September 2010 6:13 AM
> > > To: Ethernut User Chat (English)
> > > Subject: [En-Nut-Discussion] Can a thread determine its stack
> space?
> > >
> > > Hi!
> > >
> > > Can a stack determine its own stack space? I.e. I want a thread to
> > > monitor its own left free stack space. But I cannot find out how to
> > do
> > > that.
> > >
> > > There are functions that are only available if some debug settings
> > are
> > > enabled. And some of them are never available as the #defines are
> > never
> > > set and not available through nutconf.
> > >
> > > But enabling heap debugging doesn't solve the problem if a thread
> > > silently hangs up while the rest of the system is still running
> fine.
> > > And the output of NutHeapAvailable() and
> NutHeapRootRegionAvailable()
> > > in the main thread still show plenty of memory.
> > >
> > > Is there a mechanism to find a mutex where a thread is blocked on?
> > >
> > > Enabling debugging has another problem too as it multiplies some
> > stacks
> > > for init and main and others with a factor what has a general
> impact
> > on
> > > the system. So it is difficult to find the problem in a surrounding
> > > that
> > > is different from what you target on.
> > > This might also get difficult if your application needs most of
> FLASH
> > > and RAM.
> > >
> > > Best regards
> > > Ulrich
> > > _______________________________________________
> > > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> >
> > _______________________________________________
> > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> >
> >
> > _______________________________________________
> > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 
> 
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion