[Bug dynamic-link/14015] New: _dlerror_run leaks memory when called by dlsym

["wtc at google dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=14015

             Bug #: 14015
           Summary: _dlerror_run leaks memory when called by dlsym
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
        AssignedTo: unassigned@sourceware.org
        ReportedBy: wtc@google.com
    Classification: Unclassified


Created attachment 6362
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6362
Test program dlsym_leak.c

This bug may be a duplicate of bug 12878.

When we run valgrind on some unit tests in the Chromium project,
valgrind reports a memory leak in _dlerror_run.  The difference
from bug 12878 is that it is dlsym (as opposed to dlopen) that
calls _dlerror_run.

Here are three examples of this leak in Chromium bug reports. 

1. http://code.google.com/p/chromium/issues/detail?id=51770

20 bytes in 1 blocks are definitely lost in loss record 7,507 of 16,402
  calloc
(sr/local/google/valgrind-for-chromium-client/valgrind/scripts/valgrind-memcheck/coregrind/m_replacemalloc/vg_replace_malloc.c:529)
  _dlerror_run (/lib/tls/i686/cmov/libdl-2.7.so)
  dlsym (/lib/tls/i686/cmov/libdl-2.7.so)
  ...

2. http://code.google.com/p/chromium/issues/detail?id=60958

20 bytes in 1 blocks are definitely lost in loss record 8,617 of 20,802
  calloc
(sr/local/google/valgrind-for-chromium-client/valgrind/scripts/valgrind-memcheck/coregrind/m_replacemalloc/vg_replace_malloc.c:529)
  _dlerror_run (/lib/tls/i686/cmov/libdl-2.7.so)
  dlsym (/lib/tls/i686/cmov/libdl-2.7.so)
  ...

3. http://code.google.com/p/chromium/issues/detail?id=124494

Leak_DefinitelyLost
32 bytes in 1 blocks are definitely lost in loss record 4,335 of 13,650
  calloc (m_replacemalloc/vg_replace_malloc.c:1087)
  _dlerror_run (/build/buildd/eglibc-2.11.1/dlfcn/dlerror.c:142)
  dlsym (/build/buildd/eglibc-2.11.1/dlfcn/dlsym.c:71)
  ...

The dlsym calls in question look like:
    dlsym(RTLD_NEXT, "localtime_r")
or
    dlsym(RTLD_DEFAULT, "CERT_CacheOCSPResponseFromSideChannel")

I tried to write a short program that reproduces this memory leak,
but the closest I can get is to have valgrind report a "still reachable"
leak, as opposed to a "definitely lost" leak.

Steps to reproduce:

1. Save the attached test program as dlsym_leak.c.

2. Compile and link the test program:

    gcc -D_GNU_SOURCE dlsym_leak.c -ldl -lnss3

3. Run valgrind on the test program:

    valgrind --leak-check=full --show-reachable=yes ./a.out

On Ubuntu 10.04.2 LTS, I get this output from valgrind:

==12203== Memcheck, a memory error detector
==12203== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==12203== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==12203== Command: ./a.out
==12203== 
==12203== 
==12203== HEAP SUMMARY:
==12203==     in use at exit: 32 bytes in 1 blocks
==12203==   total heap usage: 1 allocs, 0 frees, 32 bytes allocated
==12203== 
==12203== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
==12203==    at 0x4C297FA: calloc (vg_replace_malloc.c:565)
==12203==    by 0x4E3431F: _dlerror_run (dlerror.c:142)
==12203==    by 0x4E34079: dlsym (dlsym.c:71)
==12203==    by 0x40059D: main (in /home/wtc/tmp/a.out)
==12203== 
==12203== LEAK SUMMARY:
==12203==    definitely lost: 0 bytes in 0 blocks
==12203==    indirectly lost: 0 bytes in 0 blocks
==12203==      possibly lost: 0 bytes in 0 blocks
==12203==    still reachable: 32 bytes in 1 blocks
==12203==         suppressed: 0 bytes in 0 blocks
==12203== 
==12203== For counts of detected and suppressed errors, rerun with: -v
==12203== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.