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

Fri Sep 24 08:54:36 CEST 2010

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