[patch] Fix BZ 19012 -- memory leak on error path in iconv_open

[Paul Pluzhnikov]

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):

==130249== HEAP SUMMARY:
==130249==     in use at exit: 23 bytes in 2 blocks
==130249==   total heap usage: 2,362 allocs, 2,360 frees, 139,354
bytes allocated
==130249==
==130249== 7 bytes in 1 blocks are definitely lost in loss record 1 of 2
==130249==    at 0x4A06C3D: malloc (vg_replace_malloc.c:299)
==130249==    by 0x4C933C9: strdup (strdup.c:42)
==130249==    by 0x4C35B70: gen_steps (gconv_db.c:264)
==130249==    by 0x4C35B70: find_derivation (gconv_db.c:663)
==130249==    by 0x4C36386: __gconv_find_transform (gconv_db.c:764)
==130249==    by 0x4C34F84: __gconv_open (gconv_open.c:110)
==130249==    by 0x4C34B17: iconv_open (iconv_open.c:71)
==130249==    by 0x4005B3: main (t.c:8)
==130249==
==130249== 16 bytes in 1 blocks are definitely lost in loss record 2 of 2
==130249==    at 0x4A06C3D: malloc (vg_replace_malloc.c:299)
==130249==    by 0x4C933C9: strdup (strdup.c:42)
==130249==    by 0x4C35B82: gen_steps (gconv_db.c:267)
==130249==    by 0x4C35B82: find_derivation (gconv_db.c:663)
==130249==    by 0x4C36386: __gconv_find_transform (gconv_db.c:764)
==130249==    by 0x4C34F84: __gconv_open (gconv_open.c:110)
==130249==    by 0x4C34B17: iconv_open (iconv_open.c:71)
==130249==    by 0x4005B3: main (t.c:8)
==130249==
==130249== LEAK SUMMARY:
==130249==    definitely lost: 23 bytes in 2 blocks
==130249==    indirectly lost: 0 bytes in 0 blocks
==130249==      possibly lost: 0 bytes in 0 blocks
==130249==    still reachable: 0 bytes in 0 blocks
==130249==         suppressed: 0 bytes in 0 blocks
==130249==

So this isn't a very serious leak, but still.

-- 
Paul Pluzhnikov