This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] memory leak in _reclaim_reent
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: newlib at sourceware dot org
- Date: Mon, 24 Jun 2013 11:36:36 +0200
- Subject: Re: [PATCH] memory leak in _reclaim_reent
- References: <BLU0-SMTP286299614CC6BC87C01382FF9890 at phx dot gbl>
- Reply-to: newlib at sourceware dot org
On Jun 23 23:05, Federico Terraneo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> While looking at the reentrancy code I've found three variables that
> are surely malloc'd, but are not freed in _reclaim_reent(). Of these,
> two variables, _misc and _signal_buf, cause a leak only if
> _REENT_SMALL is defined. The third one, _sig_func seems to always
> cause a leak.
>
> The patch for this is simple and is attached, but I have a doubt about
> it regarding _sig_func (the table of function pointers to signal
> handlers): what if a signal is raised during _reclaim_reent()? Without
> this patch, _sig_func is not freed so memory is leaked but the table
> remains valid. With this patch no memory is leaked but a signal after
> the free may be a problem.
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.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat