Bug 1734680 - glibc: Memory leak in iconv_open
Summary: glibc: Memory leak in iconv_open
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Weimer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-31 07:57 UTC by Lukas Slebodnik
Modified: 2019-07-31 15:30 UTC (History)
10 users (show)

Fixed In Version: glibc-2.29.9000-37.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-31 15:30:02 UTC


Attachments (Terms of Use)

Description Lukas Slebodnik 2019-07-31 07:57:32 UTC
Description of problem:
The latest upgrade of glibc caused  valgrind errors in few tests which
I run dayly on rawhide. And it seem sto be related to iconv_open

Version-Release number of selected component (if applicable):
glibc-2.29.9000-36.fc31.x86_64

How reproducible:
Deterministic

Steps to Reproduce:
1. cat > reproducer.c << EOF
#include <errno.h>
#include <iconv.h>

int main(void) {
    int ret;
    iconv_t encoder;

    encoder = iconv_open("UTF-32BE", "UTF-8");
    if (encoder == (iconv_t) -1) {
        return errno;
    }    
    
    ret = iconv_close(encoder);
    return ret;
}
EOF
2. gcc -Wall -Wextra reproducer.c
3. ./a.out && echo OK
4. valgrind --leak-check=full ./a.out

Actual results:
sh-5.0$ gcc -Wall -Wextra reproducer.c 
sh-5.0$ ./a.out && echo OK
OK
sh-5.0$ valgrind --leak-check=full ./a.out
==75== Memcheck, a memory error detector
==75== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==75== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==75== Command: ./a.out
==75== 
==75== 
==75== HEAP SUMMARY:
==75==     in use at exit: 208 bytes in 1 blocks
==75==   total heap usage: 11 allocs, 10 frees, 34,500 bytes allocated
==75== 
==75== 208 bytes in 1 blocks are definitely lost in loss record 1 of 1
==75==    at 0x483880B: malloc (vg_replace_malloc.c:309)
==75==    by 0x4884496: __gconv_lookup_cache (in /usr/lib64/libc-2.29.9000.so)
==75==    by 0x487C0C5: __gconv_find_transform (in /usr/lib64/libc-2.29.9000.so)
==75==    by 0x487AC5D: __gconv_open (in /usr/lib64/libc-2.29.9000.so)
==75==    by 0x487A6AA: iconv_open (in /usr/lib64/libc-2.29.9000.so)
==75==    by 0x40115C: main (in /home/build/sssd/a.out)
==75== 
==75== LEAK SUMMARY:
==75==    definitely lost: 208 bytes in 1 blocks
==75==    indirectly lost: 0 bytes in 0 blocks
==75==      possibly lost: 0 bytes in 0 blocks
==75==    still reachable: 0 bytes in 0 blocks
==75==         suppressed: 0 bytes in 0 blocks
==75== 
==75== For lists of detected and suppressed errors, rerun with: -s
==75== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Expected results:
//the same as with older version of glibc
sh-5.0$ rpm -q glibc
glibc-2.29.9000-35.fc31.x86_64
sh-5.0$ ./a.out && echo OK
OK
sh$ valgrind --leak-check=full ./a.out
==23888== Memcheck, a memory error detector
==23888== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==23888== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==23888== Command: ./a.out
==23888== 
==23888== 
==23888== HEAP SUMMARY:
==23888==     in use at exit: 0 bytes in 0 blocks
==23888==   total heap usage: 11 allocs, 11 frees, 34,500 bytes allocated
==23888== 
==23888== All heap blocks were freed -- no leaks are possible
==23888== 
==23888== For lists of detected and suppressed errors, rerun with: -s
==23888== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Additional info:

Comment 1 Florian Weimer 2019-07-31 09:45:46 UTC
I see what's going on.  We need to revert the upstream reference counting changes.  Sorry about that.

Comment 2 Florian Weimer 2019-07-31 09:56:06 UTC
Submitted upstream as well:

https://sourceware.org/ml/libc-alpha/2019-07/msg00697.html


Note You need to log in before you can comment on or make changes to this bug.