Bug 29895 - libio/tst-fopenloc leaks when GCONV_PATH not set
Summary: libio/tst-fopenloc leaks when GCONV_PATH not set
Status: RESOLVED DUPLICATE of bug 24583
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-12 22:07 UTC by dj@redhat.com
Modified: 2022-12-15 14:48 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dj@redhat.com 2022-12-12 22:07:49 UTC
While working on a project to run out in-tree testsuite against an installed system-level set of files, I encountered one test that failed.  I narrowed it down to a malloc() which is never free()'d in iconv/gconv_cache.c:

#0  __gconv_lookup_cache (toset=toset@entry=0x7ffff7f74a89 "INTERNAL", 
    fromset=fromset@entry=0x7ffff8031e30 "ISO-8859-1//", handle=handle@entry=0x7fffffffd8a0, 
    nsteps=nsteps@entry=0x7fffffffd898, flags=flags@entry=0) at gconv_cache.c:243
#1  0x00007ffff7e0563f in __gconv_find_transform (toset=toset@entry=0x7ffff7f74a89 "INTERNAL", 
    fromset=fromset@entry=0x7ffff8031e30 "ISO-8859-1//", handle=handle@entry=0x7fffffffd8a0, 
    nsteps=nsteps@entry=0x7fffffffd898, flags=flags@entry=0) at gconv_db.c:717
#2  0x00007ffff7e9ea38 in __wcsmbs_getfct (nstepsp=0x7fffffffd8e8, from=0x7ffff8031e30 "ISO-8859-1//", 
    to=0x7ffff7f74a89 "INTERNAL") at wcsmbsload.c:91
#3  __wcsmbs_named_conv (copy=copy@entry=0x7fffffffd8e0, name=name@entry=0x7ffff8031e30 "ISO-8859-1//")
    at wcsmbsload.c:251
#4  0x00007ffff7e618c0 in _IO_new_file_fopen (fp=fp@entry=0x7ffff7fff300, 
    filename=filename@entry=0x7ffff7fc1040 "../iconvdata/testdata/ISO-8859-1", mode=<optimized out>, 
    mode@entry=0x7ffff7fc1010 "r,ccs=ISO-8859-1", is32not64=is32not64@entry=1) at fileops.c:307
#5  0x00007ffff7e549ad in __fopen_internal (filename=0x7ffff7fc1040 "../iconvdata/testdata/ISO-8859-1", 
    mode=0x7ffff7fc1010 "r,ccs=ISO-8859-1", is32=1) at iofopen.c:75

It seems to be this call to malloc:

  /* We will use up to two modules.  Always allocate room for two.  */
  result = (struct __gconv_step *) malloc (2 * sizeof (struct __gconv_step));
  if (result == NULL)
    return __GCONV_NOMEM;

To reproduce, start with these two:

make test t=libio/tst-fopenloc
make test t=libio/tst-fopenloc-mem

Then, rerun the commands those run, but omit the GCONV_PATH= part.  The -mem test should indicate two leaks:

Memory not freed:
-----------------
           Address     Size     Caller
0x0000555555f10560     0xd0  at 0x320ea
0x0000555555f11590     0xd0  at 0x321bc
Comment 1 Carlos O'Donell 2022-12-15 14:48:22 UTC
This bug was detected a long time ago by the LeakSanitizer team and Florian also independently found this in 2019.

Marking this closed as a duplicate of 24583.

*** This bug has been marked as a duplicate of bug 24583 ***