This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] Fix BZ 19012 -- memory leak on error path in iconv_open
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Sat, 3 Oct 2015 20:25:22 +0200
- Subject: Re: [patch] Fix BZ 19012 -- memory leak on error path in iconv_open
- Authentication-results: sourceware.org; auth=none
- References: <CAPC3xarLZpvmAwhyVj-v6C65QkepJMhSJGfZ2ZYQATXesm94fw at mail dot gmail dot com> <5609464D dot 9030604 at redhat dot com> <CALoOobMzMe73dZweKvxvBQ=pfFEp4T0KJAjaEAvYK4vWgs2CwA at mail dot gmail dot com>
On 10/03/2015 07:19 PM, Paul Pluzhnikov wrote:
> On Mon, Sep 28, 2015 at 6:53 AM, Florian Weimer <fweimer@redhat.com> wrote:
>
>> What happens if you call iconv in a loop? Will the amount of memory
>> leaked remain bounded?
>
> I did the following test:
>
> #include <iconv.h>
>
> int main() {
> int j;
> int n_failures = 0;
>
> for (j = 0; j < 10; ++j) {
> iconv_t res = iconv_open ("UTF8", "SJIS");
> if (res == (iconv_t) -1) {
> n_failures += 1;
> } else {
> iconv_close (res);
> }
> }
> return n_failures;
> }
>
> No leaks (and exit 0) when SJIS.so and gconv-modules.cache are unmolested.
>
> When both are removed, only a single leak (and expected exit 10):
> So this isn't a very serious leak, but still.
Thanks for doing this experiment. So it's not an unbounded memory leak,
and not a security vulnerability.
Florian