Red Hat Bugzilla – Bug 123291
Memprof reports leak in getaliasbyname_r in glibc
Last modified: 2014-06-18 05:07:28 EDT
Description of problem: On many applications I run in Memprof(the one bundled in Fedora), it reports memory leaks of various sizes originating in the getaliasbyname_r function in glibc (glibc 2.3.3 for me) Version-Release number of selected component (if applicable): glibc 2.3.3, FC2test3, Memprof 0.5.1 How reproducible: Always, with a variety of applications Steps to Reproduce: 1. Open Memprof 2. Click 'Run' and enter '/usr/bin/X11/xclock' 3. Press the 'Leaks' button at the top 4. Switch to the 'leaks' tab Actual results: reports many bytes of memory leaked from the specified function Expected results: No memory leaks inside glibc Additional info: xclock was just an example. xcalc also reports leaks, and even running memprof on /bin/usleep reports a leak of 450 bytes on my system I will attach the memprof dump as well. Possibly memprof is reporting false positive, or is being run wrong?
Created attachment 100251 [details] memprof dump when running /usr/bin/X11/xclock gzipped to reduce size from 500k->12k
That must be memprof bug. Try for i in $(ldd `which xclock` | awk '$3 ~ /^\// {print $3}') `which xclock`; do nm -D $i | grep getaliasbyname && echo $i done Only libc.so.6 will be shown, and that library calls getaliasbyname_r only from getaliasbyname function and getaliasbyname is never called by libc.so itself. But the above command showed that neither xclock itself nor any of its dependencies but libc.so ever use this symbol. You can also run LD_DEBUG=all xclock 2>&1 | grep getaliasbyname to see that this function is not even looked up using dlsym. Similarly usleep,
memprof was dropped from fc5