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

[Henrik Maier]

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