This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/17805] New: memory leak when setting large, duplicate string


https://sourceware.org/bugzilla/show_bug.cgi?id=17805

            Bug ID: 17805
           Summary: memory leak when setting large, duplicate string
           Product: glibc
           Version: 2.21
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: hjl.tools at gmail dot com
                CC: drepper.fsp at gmail dot com

From

http://patchwork.sourceware.org/patch/3851/

glibc maintains a binary tree of environment strings it malloc()ed
itself.  However, it's possible for it to malloc() a string, then find
that an identical string is already in the tree.  In this case, the
memory is leaked and is not freed if the application later calls
__libc_freeres().  Fix this by freeing 'new_value' when it's unneeded.

Test case:
    #include <stdlib.h>
    #include <string.h>

    int main()
    {
        char *p = calloc(100000, 1);
        memset(p, 'A', 99999);
        setenv("TESTVAR", p, 1);
        setenv("TESTVAR", p, 1);
        free(p);
    }

Leak that was reported by valgrind:
    100,008 bytes in 1 blocks are definitely lost in loss record 1 of 1
       at 0x4C29F90: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
       by 0x4E6B3D4: __add_to_environ (setenv.c:176)
       by 0x4C31B8F: setenv (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
       by 0x400642: main (in /mnt/tmpfs/a.out)

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]