[PATCH] memory leak in _reclaim_reent

[Federico Terraneo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/24/2013 11:36 AM, Corinna Vinschen wrote:
> 
> As far as I can see, destructing _sig_func needs synchronization.
> If you free it, a _signal_r call could come in and access the
> free'd memory. If it already has been set to NULL, _signal_r calls
> _init_signal_r and reallocates it.  So we either skip this problem
> for now, or you have to make sure that nobody accesses _sig_func
> during destruction.
> 

Considering that on a second though the problem looks even worse
(malloc isn't guaranteed to by signal-safe...), I opted for a simpler
solution.

This patch has two advantages:
- - it fixes the leak about _signal_buf and _misc.
- - it leaves a comment about the _sig_func issue being unsolved, which I
  presume is better than nothing.

newlib/ChangeLog
2013-06-24  Terraneo Federico  <fede.tft@hotmail.it>

	* libc/reent/reent.c (_reclaim_reent): Free also _misc and
	  _signal_buf.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRyCkdAAoJECkLFtN5Xr9f6+cH/jLEkP/4Z9GWj30CZc4wBkCM
dD2Nn3yAFB9sURuR3If1KNbLCMH5AxeOT20BI5CkBbf78leh3p83AVooXtJNzzuH
ZViaJpNMUbr+VjqUA92xXibxduFWXPzhQyEbMWvGcUMjE9Ie2YCYPVpOe4A458yB
opwujHsuu8mpIbjKhgpjvSLtZaxyLZWQV3ECn52Zn0dxE/trEFkkscktAZzswjbO
C+ZIlo47DucjoLYTjdKU1Y0n1y4+0zQ+Hm26Eu4gGuMnLuufopmDU4c8ZwqShsyc
umpDzfYAmwRb6dHd7P1gKHRh22YvUceYIyjbwA3GDTTdF6MZV+yiiTSgGCD+UZI=
=kYb6
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reclaim_reent2.patch
Type: text/x-patch
Size: 809 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20130624/4df1da5f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reclaim_reent2.patch.sig
Type: application/octet-stream
Size: 287 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20130624/4df1da5f/attachment.obj>