This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/14015] New: _dlerror_run leaks memory when called by dlsym
- From: "wtc at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Tue, 24 Apr 2012 18:09:22 +0000
- Subject: [Bug dynamic-link/14015] New: _dlerror_run leaks memory when called by dlsym
- Auto-submitted: auto-generated
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.