public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Reclaim _REENT_MP_P5S in _reclaim_reent
@ 2023-11-16  1:12 chrisj
  2023-11-16  9:15 ` Corinna Vinschen
  0 siblings, 1 reply; 4+ messages in thread
From: chrisj @ 2023-11-16  1:12 UTC (permalink / raw)
  To: newlib; +Cc: Chris Johns

From: Chris Johns <chrisj@rtems.org>

The change fixes a memory leak in threads that clean up using
_reclaim_reent.

RTEMS: Closes #4967
---
 newlib/libc/reent/reent.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/newlib/libc/reent/reent.c b/newlib/libc/reent/reent.c
index db80ca06e..6bb271b9a 100644
--- a/newlib/libc/reent/reent.c
+++ b/newlib/libc/reent/reent.c
@@ -59,6 +59,17 @@ _reclaim_reent (struct _reent *ptr)
 	}
       if (_REENT_MP_RESULT(ptr))
 	_free_r (ptr, _REENT_MP_RESULT(ptr));
+      if (_REENT_MP_P5S(ptr))
+        {
+         struct _Bigint *thisone, *nextone;
+         nextone = _REENT_MP_P5S(ptr);
+         while (nextone)
+           {
+             thisone = nextone;
+             nextone = nextone->_next;
+             _free_r (ptr, thisone);
+           }
+       }
 #ifdef _REENT_SMALL
       }
 #endif
-- 
2.37.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Reclaim _REENT_MP_P5S in _reclaim_reent
  2023-11-16  1:12 [PATCH] Reclaim _REENT_MP_P5S in _reclaim_reent chrisj
@ 2023-11-16  9:15 ` Corinna Vinschen
  2023-11-16 21:17   ` Chris Johns
  0 siblings, 1 reply; 4+ messages in thread
From: Corinna Vinschen @ 2023-11-16  9:15 UTC (permalink / raw)
  To: newlib

On Nov 16 12:12, chrisj@rtems.org wrote:
> From: Chris Johns <chrisj@rtems.org>
> 
> The change fixes a memory leak in threads that clean up using
> _reclaim_reent.
> 
> RTEMS: Closes #4967
> ---
>  newlib/libc/reent/reent.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/newlib/libc/reent/reent.c b/newlib/libc/reent/reent.c
> index db80ca06e..6bb271b9a 100644
> --- a/newlib/libc/reent/reent.c
> +++ b/newlib/libc/reent/reent.c
> @@ -59,6 +59,17 @@ _reclaim_reent (struct _reent *ptr)
>  	}
>        if (_REENT_MP_RESULT(ptr))
>  	_free_r (ptr, _REENT_MP_RESULT(ptr));
> +      if (_REENT_MP_P5S(ptr))
> +        {
> +         struct _Bigint *thisone, *nextone;
> +         nextone = _REENT_MP_P5S(ptr);
> +         while (nextone)
> +           {
> +             thisone = nextone;
> +             nextone = nextone->_next;
> +             _free_r (ptr, thisone);
> +           }
> +       }

The p5s data is allocated using Balloc, so the pointers are in freelist
and should already be free'd at this point, starting at line 42.

Please explain what happens and why free'ing the freelist is not
sufficient in this case, preferredly as part of the commit message.


Thanks,
Corinna


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Reclaim _REENT_MP_P5S in _reclaim_reent
  2023-11-16  9:15 ` Corinna Vinschen
@ 2023-11-16 21:17   ` Chris Johns
  2023-11-17 12:08     ` Corinna Vinschen
  0 siblings, 1 reply; 4+ messages in thread
From: Chris Johns @ 2023-11-16 21:17 UTC (permalink / raw)
  To: newlib

On 16/11/2023 8:15 pm, Corinna Vinschen wrote:
> On Nov 16 12:12, chrisj@rtems.org wrote:
>> From: Chris Johns <chrisj@rtems.org>
>>
>> The change fixes a memory leak in threads that clean up using
>> _reclaim_reent.
>>
>> RTEMS: Closes #4967
>> ---
>>  newlib/libc/reent/reent.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/newlib/libc/reent/reent.c b/newlib/libc/reent/reent.c
>> index db80ca06e..6bb271b9a 100644
>> --- a/newlib/libc/reent/reent.c
>> +++ b/newlib/libc/reent/reent.c
>> @@ -59,6 +59,17 @@ _reclaim_reent (struct _reent *ptr)
>>  	}
>>        if (_REENT_MP_RESULT(ptr))
>>  	_free_r (ptr, _REENT_MP_RESULT(ptr));
>> +      if (_REENT_MP_P5S(ptr))
>> +        {
>> +         struct _Bigint *thisone, *nextone;
>> +         nextone = _REENT_MP_P5S(ptr);
>> +         while (nextone)
>> +           {
>> +             thisone = nextone;
>> +             nextone = nextone->_next;
>> +             _free_r (ptr, thisone);
>> +           }
>> +       }
> 
> The p5s data is allocated using Balloc, so the pointers are in freelist
> and should already be free'd at this point, starting at line 42.

Yes however P5S blocks allocated by Balloc via i2b are not passed to Bfree.

> Please explain what happens and why free'ing the freelist is not
> sufficient in this case, preferredly as part of the commit message.

Yes good idea. How about:

The _REENT_MP_P5S blocks are allocated using Balloc via i2b and linked in the
pow5mult call. As a result these blocks are not on the freelist managed by the
Bfree call. This change fixes a memory leak in threads that clean up using
_reclaim_reent.

Chris

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Reclaim _REENT_MP_P5S in _reclaim_reent
  2023-11-16 21:17   ` Chris Johns
@ 2023-11-17 12:08     ` Corinna Vinschen
  0 siblings, 0 replies; 4+ messages in thread
From: Corinna Vinschen @ 2023-11-17 12:08 UTC (permalink / raw)
  To: newlib

On Nov 17 08:17, Chris Johns wrote:
> On 16/11/2023 8:15 pm, Corinna Vinschen wrote:
> > On Nov 16 12:12, chrisj@rtems.org wrote:
> >> From: Chris Johns <chrisj@rtems.org>
> >>
> >> The change fixes a memory leak in threads that clean up using
> >> _reclaim_reent.
> >>
> >> RTEMS: Closes #4967
> >> ---
> >>  newlib/libc/reent/reent.c | 11 +++++++++++
> >>  1 file changed, 11 insertions(+)
> >>
> >> diff --git a/newlib/libc/reent/reent.c b/newlib/libc/reent/reent.c
> >> index db80ca06e..6bb271b9a 100644
> >> --- a/newlib/libc/reent/reent.c
> >> +++ b/newlib/libc/reent/reent.c
> >> @@ -59,6 +59,17 @@ _reclaim_reent (struct _reent *ptr)
> >>  	}
> >>        if (_REENT_MP_RESULT(ptr))
> >>  	_free_r (ptr, _REENT_MP_RESULT(ptr));
> >> +      if (_REENT_MP_P5S(ptr))
> >> +        {
> >> +         struct _Bigint *thisone, *nextone;
> >> +         nextone = _REENT_MP_P5S(ptr);
> >> +         while (nextone)
> >> +           {
> >> +             thisone = nextone;
> >> +             nextone = nextone->_next;
> >> +             _free_r (ptr, thisone);
> >> +           }
> >> +       }
> > 
> > The p5s data is allocated using Balloc, so the pointers are in freelist
> > and should already be free'd at this point, starting at line 42.
> 
> Yes however P5S blocks allocated by Balloc via i2b are not passed to Bfree.

Aaah, right, it really never does.

> > Please explain what happens and why free'ing the freelist is not
> > sufficient in this case, preferredly as part of the commit message.
> 
> Yes good idea. How about:
> 
> The _REENT_MP_P5S blocks are allocated using Balloc via i2b and linked in the
> pow5mult call. As a result these blocks are not on the freelist managed by the
> Bfree call. This change fixes a memory leak in threads that clean up using
> _reclaim_reent.

Yeah, sounds good.  Please resend with this commit message.


Thanks,
Corinna


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-11-17 12:08 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-16  1:12 [PATCH] Reclaim _REENT_MP_P5S in _reclaim_reent chrisj
2023-11-16  9:15 ` Corinna Vinschen
2023-11-16 21:17   ` Chris Johns
2023-11-17 12:08     ` Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).