Re: Two Resource Leaks

2021-03-29 Thread Richi Dubey 
realview_pbx_a9_qemu

Cool, that's interesting.

On Mon, Mar 29, 2021 at 6:38 PM Joel Sherrill  wrote:

>
>
> On Mon, Mar 29, 2021 at 7:56 AM Richi Dubey  wrote:
>
>>
>> https://docs.google.com/spreadsheets/d/12FkAE6Wvo0dDw9D75p-w8UISc8_aOKQqntvruGGdeN4/edit#gid=0
>>
>> This sheet has rtems-test result comparisons between different SMP
>> schedulers set as default schedulers and has results from last the 2
>> months. This might be of help to you.
>>
>
> Thanks! Which BSP?
>
> I ran mips/jmr3904 yesterday and need to look at all those results. It is
> one of my favorite BSPs to test on because it has no valid addresses
> between 0x0 and 0x7fff. That tends to catch any random writes. It has
> ~14 failiures now.
>
>>
>> On Sat, Mar 27, 2021 at 9:50 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>>
 On 27/03/2021 16:08, Joel Sherrill wrote:

 > The issue I found is different and won't happen on every target or
 > bsp.
 >
 > Psim has 6-9 failures even after freeing the right stack address.
 >
 >
 > The stack address and now (I think) size saved for later use are
 wrong
 > and this leads to multiple failures.
 I work on a fix. psim seems to be a good platform for these tests.

>>>
>>> I put a patch for the address issue but I think the fundamental issue is
>>> you changed the semantics of what was stored in the stack structure. You
>>> probably want a different approach but this is at least a good
>>> temporary fix.
>>>
>>> And something different on Libbsd. But not sure.
>>>
>>> I think Richi has raised the issue that there are some recently
>>> introduced failures. Not sure how many are this.
>>>

 --
 embedded brains GmbH
 Herr Sebastian HUBER
 Dornierstr. 4
 82178 Puchheim
 Germany
 email: sebastian.hu...@embedded-brains.de
 phone: +49-89-18 94 741 - 16
 fax:   +49-89-18 94 741 - 08

 Registergericht: Amtsgericht München
 Registernummer: HRB 157899
 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
 Unsere Datenschutzerklärung finden Sie hier:
 https://embedded-brains.de/datenschutzerklaerung/

 ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-29 Thread Joel Sherrill 
On Mon, Mar 29, 2021 at 7:56 AM Richi Dubey  wrote:

>
> https://docs.google.com/spreadsheets/d/12FkAE6Wvo0dDw9D75p-w8UISc8_aOKQqntvruGGdeN4/edit#gid=0
>
> This sheet has rtems-test result comparisons between different SMP
> schedulers set as default schedulers and has results from last the 2
> months. This might be of help to you.
>

Thanks! Which BSP?

I ran mips/jmr3904 yesterday and need to look at all those results. It is
one of my favorite BSPs to test on because it has no valid addresses
between 0x0 and 0x7fff. That tends to catch any random writes. It has
~14 failiures now.

>
> On Sat, Mar 27, 2021 at 9:50 PM Joel Sherrill  wrote:
>
>>
>>
>> On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> On 27/03/2021 16:08, Joel Sherrill wrote:
>>>
>>> > The issue I found is different and won't happen on every target or
>>> > bsp.
>>> >
>>> > Psim has 6-9 failures even after freeing the right stack address.
>>> >
>>> >
>>> > The stack address and now (I think) size saved for later use are wrong
>>> > and this leads to multiple failures.
>>> I work on a fix. psim seems to be a good platform for these tests.
>>>
>>
>> I put a patch for the address issue but I think the fundamental issue is
>> you changed the semantics of what was stored in the stack structure. You
>> probably want a different approach but this is at least a good
>> temporary fix.
>>
>> And something different on Libbsd. But not sure.
>>
>> I think Richi has raised the issue that there are some recently
>> introduced failures. Not sure how many are this.
>>
>>>
>>> --
>>> embedded brains GmbH
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: sebastian.hu...@embedded-brains.de
>>> phone: +49-89-18 94 741 - 16
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>>
>>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-29 Thread Richi Dubey 
https://docs.google.com/spreadsheets/d/12FkAE6Wvo0dDw9D75p-w8UISc8_aOKQqntvruGGdeN4/edit#gid=0

This sheet has rtems-test result comparisons between different SMP
schedulers set as default schedulers and has results from last the 2
months. This might be of help to you.

On Sat, Mar 27, 2021 at 9:50 PM Joel Sherrill  wrote:

>
>
> On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 27/03/2021 16:08, Joel Sherrill wrote:
>>
>> > The issue I found is different and won't happen on every target or
>> > bsp.
>> >
>> > Psim has 6-9 failures even after freeing the right stack address.
>> >
>> >
>> > The stack address and now (I think) size saved for later use are wrong
>> > and this leads to multiple failures.
>> I work on a fix. psim seems to be a good platform for these tests.
>>
>
> I put a patch for the address issue but I think the fundamental issue is
> you changed the semantics of what was stored in the stack structure. You
> probably want a different approach but this is at least a good
> temporary fix.
>
> And something different on Libbsd. But not sure.
>
> I think Richi has raised the issue that there are some recently introduced
> failures. Not sure how many are this.
>
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-27 Thread Joel Sherrill 
On Sat, Mar 27, 2021, 1:38 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 27/03/2021 17:20, Joel Sherrill wrote:
>
> >
> >
> > On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber
> >  > > wrote:
> >
> > On 27/03/2021 16:08, Joel Sherrill wrote:
> >
> > > The issue I found is different and won't happen on every
> > target or
> > > bsp.
> > >
> > > Psim has 6-9 failures even after freeing the right stack
> > address.
> > >
> > >
> > > The stack address and now (I think) size saved for later use are
> > wrong
> > > and this leads to multiple failures.
> > I work on a fix. psim seems to be a good platform for these tests.
> >
> >
> > I put a patch for the address issue but I think the fundamental issue
> > is you changed the semantics of what was stored in the stack
> > structure. You probably want a different approach but this is at least
> > a good temporary fix.
>
> I checked in a fix. However, I still get two unexpected failures:
>

Great.


> Failures:
>   fsimfsgeneric01.exe
>   psxkey08.exe
>
> A rtems_resource_snapshot_check() is not happy.
>

Did you manage to see what was leaking?

And did you try the non-network tests in libbsd. Those failing on beatnik
is what caused me to start looking at psim. Syscalls01 was a workspace
mismatch on the resource check.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-27 Thread Sebastian Huber 

On 27/03/2021 17:20, Joel Sherrill wrote:




On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber 
> wrote:


On 27/03/2021 16:08, Joel Sherrill wrote:

>     The issue I found is different and won't happen on every
target or
>     bsp.
>
>     Psim has 6-9 failures even after freeing the right stack
address.
>
>
> The stack address and now (I think) size saved for later use are
wrong
> and this leads to multiple failures.
I work on a fix. psim seems to be a good platform for these tests.


I put a patch for the address issue but I think the fundamental issue 
is you changed the semantics of what was stored in the stack 
structure. You probably want a different approach but this is at least 
a good temporary fix.


I checked in a fix. However, I still get two unexpected failures:

Failures:
 fsimfsgeneric01.exe
 psxkey08.exe

A rtems_resource_snapshot_check() is not happy.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-27 Thread Joel Sherrill 
On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 27/03/2021 16:08, Joel Sherrill wrote:
>
> > The issue I found is different and won't happen on every target or
> > bsp.
> >
> > Psim has 6-9 failures even after freeing the right stack address.
> >
> >
> > The stack address and now (I think) size saved for later use are wrong
> > and this leads to multiple failures.
> I work on a fix. psim seems to be a good platform for these tests.
>

I put a patch for the address issue but I think the fundamental issue is
you changed the semantics of what was stored in the stack structure. You
probably want a different approach but this is at least a good
temporary fix.

And something different on Libbsd. But not sure.

I think Richi has raised the issue that there are some recently introduced
failures. Not sure how many are this.

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-27 Thread Sebastian Huber 

On 26/03/2021 22:51, Joel Sherrill wrote:

Jennifer has been working on a network driver and had some odd 
failures in libbsd. I suggested turning on rtems debug and that caused 
a number of libbsd tests to fail.


You can also enable the FreeBSD invariants support. In 
rtems-bsd-kernel-space.h:


#define INVARIANTS 1

#define INVARIANTS_SUPPORT 1

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-27 Thread Sebastian Huber 

On 27/03/2021 16:08, Joel Sherrill wrote:


The issue I found is different and won't happen on every target or
bsp.

Psim has 6-9 failures even after freeing the right stack address.


The stack address and now (I think) size saved for later use are wrong 
and this leads to multiple failures.

I work on a fix. psim seems to be a good platform for these tests.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-27 Thread Joel Sherrill 
On Sat, Mar 27, 2021 at 8:53 AM Joel Sherrill  wrote:

>
>
> On Sat, Mar 27, 2021, 12:04 AM Richi Dubey  wrote:
>
>> I believe that cause of the recent commits in the last two months, these
>> are the tests that have started failing on master:
>> dl09.exe
>> psxpasswd02.exe
>> pwdgrp01.exe
>> shell01.exe
>> sptimecounter02.exe
>> ttest02.exe
>>
>> and a timeout:
>> smpmrsp01.ex
>>
>
> The password ones are for an incorrect change to pwdgrp.c to assert if
> mkdir fails creating /etc. That should account for pwdgrp, paxpasswd02, and
> shell01. This code needs to turn into a (void) rather than an assert.
>
> https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/pwdgrp.c#n74
>
> And looking at git makes me realise that I didn't push the fix for that.
> It is in my tree. Sorry.
>

 pushed this and per rtems-test, psim has 9 failures.

>
> The issue I found is different and won't happen on every target or bsp.
>
> Psim has 6-9 failures even after freeing the right stack address.
>

The stack address and now (I think) size saved for later use are wrong and
this leads to multiple failures.



>
>
>>
>> On Sat, Mar 27, 2021 at 3:21 AM Joel Sherrill  wrote:
>>
>>> Hi
>>>
>>> Jennifer has been working on a network driver and had some odd failures
>>> in libbsd. I suggested turning on rtems debug and that caused a number of
>>> libbsd tests to fail. She pointed me in the right direction and I found
>>> that the following patch resulted in the stack address being freed
>>> including an "align up" adjustment in some cases. This looks to be from
>>> something Sebastian committed early this month.
>>>
>>>
>>> https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1
>>>
>>> I am not sure how that wasn't noticed since about 40 tests were failing
>>> on psim due to that.
>>>
>>> I have attached a straightforward patch to address this issue.
>>>
>>> Unfortunately, even with this patch and using the RTEMS hash just before
>>> this patch program01 and syscalls01 in libbsd fail. I debugged into
>>> syscalls01 enough to find that there are 7 blocks at the beginning of one
>>> of the tests and 5 after. There is another leak and I tried using the has
>>> before Sebastian's change above but it is still leaking.
>>>
>>> On top of that, psxconfig01 and spconfig01 are failing on psim which
>>> appears to be independent. I am not sure what these are but it is something
>>> about minimum stack size not matching. Since I was looking for stack memory
>>> issues, I started to investigate these but decided they were not
>>> allocation/free issues.
>>>
>>> Help really appreciated in addressing these leaks.
>>>
>>> Thanks.
>>>
>>> --joel
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-27 Thread Joel Sherrill 
On Sat, Mar 27, 2021, 12:04 AM Richi Dubey  wrote:

> I believe that cause of the recent commits in the last two months, these
> are the tests that have started failing on master:
> dl09.exe
> psxpasswd02.exe
> pwdgrp01.exe
> shell01.exe
> sptimecounter02.exe
> ttest02.exe
>
> and a timeout:
> smpmrsp01.ex
>

The password ones are for an incorrect change to pwdgrp.c to assert if
mkdir fails creating /etc. That should account for pwdgrp, paxpasswd02, and
shell01. This code needs to turn into a (void) rather than an assert.

https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/pwdgrp.c#n74

And looking at git makes me realise that I didn't push the fix for that. It
is in my tree. Sorry.

The issue I found is different and won't happen on every target or bsp.

Psim has 6-9 failures even after freeing the right stack address.



>
> On Sat, Mar 27, 2021 at 3:21 AM Joel Sherrill  wrote:
>
>> Hi
>>
>> Jennifer has been working on a network driver and had some odd failures
>> in libbsd. I suggested turning on rtems debug and that caused a number of
>> libbsd tests to fail. She pointed me in the right direction and I found
>> that the following patch resulted in the stack address being freed
>> including an "align up" adjustment in some cases. This looks to be from
>> something Sebastian committed early this month.
>>
>>
>> https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1
>>
>> I am not sure how that wasn't noticed since about 40 tests were failing
>> on psim due to that.
>>
>> I have attached a straightforward patch to address this issue.
>>
>> Unfortunately, even with this patch and using the RTEMS hash just before
>> this patch program01 and syscalls01 in libbsd fail. I debugged into
>> syscalls01 enough to find that there are 7 blocks at the beginning of one
>> of the tests and 5 after. There is another leak and I tried using the has
>> before Sebastian's change above but it is still leaking.
>>
>> On top of that, psxconfig01 and spconfig01 are failing on psim which
>> appears to be independent. I am not sure what these are but it is something
>> about minimum stack size not matching. Since I was looking for stack memory
>> issues, I started to investigate these but decided they were not
>> allocation/free issues.
>>
>> Help really appreciated in addressing these leaks.
>>
>> Thanks.
>>
>> --joel
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-26 Thread Richi Dubey 
I believe that cause of the recent commits in the last two months, these
are the tests that have started failing on master:
dl09.exe
psxpasswd02.exe
pwdgrp01.exe
shell01.exe
sptimecounter02.exe
ttest02.exe

and a timeout:
smpmrsp01.ex


On Sat, Mar 27, 2021 at 3:21 AM Joel Sherrill  wrote:

> Hi
>
> Jennifer has been working on a network driver and had some odd failures in
> libbsd. I suggested turning on rtems debug and that caused a number of
> libbsd tests to fail. She pointed me in the right direction and I found
> that the following patch resulted in the stack address being freed
> including an "align up" adjustment in some cases. This looks to be from
> something Sebastian committed early this month.
>
>
> https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1
>
> I am not sure how that wasn't noticed since about 40 tests were failing on
> psim due to that.
>
> I have attached a straightforward patch to address this issue.
>
> Unfortunately, even with this patch and using the RTEMS hash just before
> this patch program01 and syscalls01 in libbsd fail. I debugged into
> syscalls01 enough to find that there are 7 blocks at the beginning of one
> of the tests and 5 after. There is another leak and I tried using the has
> before Sebastian's change above but it is still leaking.
>
> On top of that, psxconfig01 and spconfig01 are failing on psim which
> appears to be independent. I am not sure what these are but it is something
> about minimum stack size not matching. Since I was looking for stack memory
> issues, I started to investigate these but decided they were not
> allocation/free issues.
>
> Help really appreciated in addressing these leaks.
>
> Thanks.
>
> --joel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Two Resource Leaks

2021-03-26 Thread Joel Sherrill 
Hi

Jennifer has been working on a network driver and had some odd failures in
libbsd. I suggested turning on rtems debug and that caused a number of
libbsd tests to fail. She pointed me in the right direction and I found
that the following patch resulted in the stack address being freed
including an "align up" adjustment in some cases. This looks to be from
something Sebastian committed early this month.

https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1

I am not sure how that wasn't noticed since about 40 tests were failing on
psim due to that.

I have attached a straightforward patch to address this issue.

Unfortunately, even with this patch and using the RTEMS hash just before
this patch program01 and syscalls01 in libbsd fail. I debugged into
syscalls01 enough to find that there are 7 blocks at the beginning of one
of the tests and 5 after. There is another leak and I tried using the has
before Sebastian's change above but it is still leaking.

On top of that, psxconfig01 and spconfig01 are failing on psim which
appears to be independent. I am not sure what these are but it is something
about minimum stack size not matching. Since I was looking for stack memory
issues, I started to investigate these but decided they were not
allocation/free issues.

Help really appreciated in addressing these leaks.

Thanks.

--joel
From b617122b4c8999284800c2f1a89954edf8e2cd14 Mon Sep 17 00:00:00 2001
From: Joel Sherrill 
Date: Thu, 25 Mar 2021 18:08:23 -0500
Subject: [PATCH 2/2] cpukit stack: Keep and free correct stack address

---
 cpukit/include/rtems/score/stack.h | 2 ++
 cpukit/include/rtems/score/stackimpl.h | 7 +--
 cpukit/score/src/threadinitialize.c| 3 ++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/score/stack.h b/cpukit/include/rtems/score/stack.h
index 23421cf..5498145 100644
--- a/cpukit/include/rtems/score/stack.h
+++ b/cpukit/include/rtems/score/stack.h
@@ -52,6 +52,8 @@ extern "C" {
 typedef struct {
   /** This is the stack size. */
   size_t  size;
+  /** This is the allocated address of stack and must be the one freed. */
+  void   *address_to_free;
   /** This is the low memory address of stack. */
   void   *area;
 }   Stack_Control;
diff --git a/cpukit/include/rtems/score/stackimpl.h b/cpukit/include/rtems/score/stackimpl.h
index c152060..92d08e9 100644
--- a/cpukit/include/rtems/score/stackimpl.h
+++ b/cpukit/include/rtems/score/stackimpl.h
@@ -41,17 +41,20 @@ extern "C" {
  * reserved for a stack.
  *
  * @param[out] the_stack The stack to initialize.
+ * @param address_to_free The address allocated which must be freed.
  * @param starting_address The starting_address for the new stack.
  * @param size The size of the stack in bytes.
  */
 RTEMS_INLINE_ROUTINE void _Stack_Initialize (
   Stack_Control *the_stack,
+  void  *address_to_free,
   void  *starting_address,
   size_t size
 )
 {
-  the_stack->area = starting_address;
-  the_stack->size = size;
+  the_stack->address_to_free = address_to_free;
+  the_stack->area= starting_address;
+  the_stack->size= size;
 }
 
 /**
diff --git a/cpukit/score/src/threadinitialize.c b/cpukit/score/src/threadinitialize.c
index 18c98c6..c12436d 100644
--- a/cpukit/score/src/threadinitialize.c
+++ b/cpukit/score/src/threadinitialize.c
@@ -83,7 +83,7 @@ void _Thread_Free(
*  Free the rest of the memory associated with this task
*  and set the associated pointers to NULL for safety.
*/
-  ( *the_thread->Start.stack_free )( the_thread->Start.Initial_stack.area );
+  ( *the_thread->Start.stack_free )( the_thread->Start.Initial_stack.address_to_free );
 
 #if defined(RTEMS_SMP)
   _ISR_lock_Destroy( _thread->Scheduler.Lock );
@@ -158,6 +158,7 @@ static bool _Thread_Try_initialize(
 
   _Stack_Initialize(
 _thread->Start.Initial_stack,
+config->stack_area,
 stack_begin,
 stack_end - stack_begin
   );
-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel