Hide Forgot
Description of problem: ls -l / makes some memory leaks Version-Release number of selected component (if applicable): coreutils-8.4-13.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. valgrind ls -l / Actual results: dr-xr-xr-x. 2 root root 4096 Nov 7 10:51 bin dr-xr-xr-x. 5 root root 1024 Nov 7 11:08 boot drwxr-xr-x. 19 root root 3720 Nov 7 11:08 dev drwxr-xr-x. 86 root root 4096 Nov 7 11:09 etc drwxr-xr-x. 4 root root 4096 Nov 7 10:53 home dr-xr-xr-x. 11 root root 4096 Nov 7 10:51 lib dr-xr-xr-x. 9 root root 12288 Nov 7 10:51 lib64 drwx------. 2 root root 16384 Nov 7 10:44 lost+found drwxr-xr-x. 2 root root 4096 Dec 4 2009 media drwxr-xr-x. 5 root root 4096 Nov 7 11:09 mnt drwxr-xr-x. 2 root root 4096 Dec 4 2009 opt dr-xr-xr-x. 169 root root 0 Nov 7 06:08 proc dr-xr-x---. 2 root root 4096 Nov 7 10:53 root dr-xr-xr-x. 2 root root 12288 Nov 7 10:51 sbin drwxr-xr-x. 7 root root 0 Nov 7 06:08 selinux drwxr-xr-x. 2 root root 4096 Dec 4 2009 srv drwxr-xr-x. 13 root root 0 Nov 7 06:08 sys drwxrwxrwt. 5 root root 4096 Nov 7 11:10 tmp drwxr-xr-x. 13 root root 4096 Nov 7 10:46 usr drwxr-xr-x. 21 root root 4096 Nov 7 11:09 var ==6604== Memcheck, a memory error detector ==6604== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==6604== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==6604== Command: ls -l / ==6604== Parent PID: 6402 ==6604== ==6604== Conditional jump or move depends on uninitialised value(s) ==6604== at 0x56E59B0: __GI___strcasecmp_l (in /lib64/libc-2.12.so) ==6604== by 0x567FE84: __gconv_open (in /lib64/libc-2.12.so) ==6604== by 0x568D417: _nl_find_msg (in /lib64/libc-2.12.so) ==6604== by 0x568DBE3: __dcigettext (in /lib64/libc-2.12.so) ==6604== by 0x409CA3: ??? (in /bin/ls) ==6604== by 0x567EC9C: (below main) (in /lib64/libc-2.12.so) ==6604== ==6604== Use of uninitialised value of size 8 ==6604== at 0x56E5DD4: __GI___strcasecmp_l (in /lib64/libc-2.12.so) ==6604== by 0x567FE84: __gconv_open (in /lib64/libc-2.12.so) ==6604== by 0x568D417: _nl_find_msg (in /lib64/libc-2.12.so) ==6604== by 0x568DBE3: __dcigettext (in /lib64/libc-2.12.so) ==6604== by 0x409CA3: ??? (in /bin/ls) ==6604== by 0x567EC9C: (below main) (in /lib64/libc-2.12.so) ==6604== ==6604== Use of uninitialised value of size 8 ==6604== at 0x56E5DD8: __GI___strcasecmp_l (in /lib64/libc-2.12.so) ==6604== by 0x567FE84: __gconv_open (in /lib64/libc-2.12.so) ==6604== by 0x568D417: _nl_find_msg (in /lib64/libc-2.12.so) ==6604== by 0x568DBE3: __dcigettext (in /lib64/libc-2.12.so) ==6604== by 0x409CA3: ??? (in /bin/ls) ==6604== by 0x567EC9C: (below main) (in /lib64/libc-2.12.so) ==6604== ==6604== ==6604== HEAP SUMMARY: ==6604== in use at exit: 20,592 bytes in 49 blocks ==6604== total heap usage: 322 allocs, 273 frees, 83,580 bytes allocated ==6604== ==6604== LEAK SUMMARY: ==6604== definitely lost: 28 bytes in 1 blocks ==6604== indirectly lost: 0 bytes in 0 blocks ==6604== possibly lost: 0 bytes in 0 blocks ==6604== still reachable: 20,564 bytes in 48 blocks ==6604== suppressed: 0 bytes in 0 blocks ==6604== Rerun with --leak-check=full to see details of leaked memory ==6604== ==6604== For counts of detected and suppressed errors, rerun with: -v ==6604== Use --track-origins=yes to see where uninitialised values come from ==6604== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 6 from 6) Expected results: ==7305== HEAP SUMMARY: ==7305== in use at exit: 0 bytes in 0 blocks ==7305== total heap usage: 88 allocs, 88 frees, 12,029 bytes allocated ==7305== ==7305== All heap blocks were freed -- no leaks are possible ==7305== ==7305== For counts of detected and suppressed errors, rerun with: -v ==7305== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) Additional info:
Thanks for reporting that. There is indeed a leak, but it's not in coreutils per se. This suggests that it is in libselinux's selinux_raw_to_trans_context function. $ valgrind --leak-check=full ls -l / / / > /dev/null ==4986== Memcheck, a memory error detector ==4986== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==4986== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==4986== Command: ls -l / / / ==4986== ==4986== ==4986== HEAP SUMMARY: ==4986== in use at exit: 21,296 bytes in 75 blocks ==4986== total heap usage: 631 allocs, 556 frees, 162,787 bytes allocated ==4986== ==4986== 28 bytes in 1 blocks are definitely lost in loss record 7 of 16 ==4986== at 0x4A074CD: malloc (vg_replace_malloc.c:236) ==4986== by 0x3A580863D1: strdup (in /lib64/libc-2.14.90.so) ==4986== by 0x3A59C1229C: selinux_raw_to_trans_context (in /lib64/libselinux.so.1) ==4986== by 0x3A59C0EBA9: lgetfilecon (in /lib64/libselinux.so.1) ==4986== by 0x411488: rpl_lgetfilecon (getfilecon.c:78) ==4986== by 0x407164: gobble_file.constprop.45 (ls.c:2878) ==4986== by 0x402E8C: main (ls.c:1397) ==4986== ==4986== 56 bytes in 2 blocks are definitely lost in loss record 11 of 16 ==4986== at 0x4A074CD: malloc (vg_replace_malloc.c:236) ==4986== by 0x3A580863D1: strdup (in /lib64/libc-2.14.90.so) ==4986== by 0x3A59C1233B: selinux_raw_to_trans_context (in /lib64/libselinux.so.1) ==4986== by 0x3A59C0EBA9: lgetfilecon (in /lib64/libselinux.so.1) ==4986== by 0x411488: rpl_lgetfilecon (getfilecon.c:78) ==4986== by 0x407164: gobble_file.constprop.45 (ls.c:2878) ==4986== by 0x402E8C: main (ls.c:1397) ==4986== ==4986== LEAK SUMMARY: ==4986== definitely lost: 84 bytes in 3 blocks ==4986== indirectly lost: 0 bytes in 0 blocks ==4986== possibly lost: 0 bytes in 0 blocks ==4986== still reachable: 21,212 bytes in 72 blocks ==4986== suppressed: 0 bytes in 0 blocks
Because it's libselinux bug now: # rpm -qa libselinux\* libselinux-devel-2.0.94-5.2.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 libselinux-utils-2.0.94-5.2.el6.x86_64 libselinux-python-2.0.94-5.2.el6.x86_64 # valgrind --leak-check=full ls -l / / / > /dev/null ==5661== Memcheck, a memory error detector ==5661== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==5661== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==5661== Command: ls -l / / / ==5661== ==5661== Conditional jump or move depends on uninitialised value(s) ==5661== at 0x3E0188354B: __GI___strcasecmp_l (in /lib64/libc-2.12.so) ==5661== by 0x3E0181FF04: __gconv_open (in /lib64/libc-2.12.so) ==5661== by 0x3E0182D397: _nl_find_msg (in /lib64/libc-2.12.so) ==5661== by 0x3E0182DB63: __dcigettext (in /lib64/libc-2.12.so) ==5661== by 0x409CD3: ??? (in /bin/ls) ==5661== by 0x3E0181ECDC: (below main) (in /lib64/libc-2.12.so) ==5661== ==5661== Use of uninitialised value of size 8 ==5661== at 0x3E01885684: __GI___strcasecmp_l (in /lib64/libc-2.12.so) ==5661== by 0x3E0181FF04: __gconv_open (in /lib64/libc-2.12.so) ==5661== by 0x3E0182D397: _nl_find_msg (in /lib64/libc-2.12.so) ==5661== by 0x3E0182DB63: __dcigettext (in /lib64/libc-2.12.so) ==5661== by 0x409CD3: ??? (in /bin/ls) ==5661== by 0x3E0181ECDC: (below main) (in /lib64/libc-2.12.so) ==5661== ==5661== Use of uninitialised value of size 8 ==5661== at 0x3E01885688: __GI___strcasecmp_l (in /lib64/libc-2.12.so) ==5661== by 0x3E0181FF04: __gconv_open (in /lib64/libc-2.12.so) ==5661== by 0x3E0182D397: _nl_find_msg (in /lib64/libc-2.12.so) ==5661== by 0x3E0182DB63: __dcigettext (in /lib64/libc-2.12.so) ==5661== by 0x409CD3: ??? (in /bin/ls) ==5661== by 0x3E0181ECDC: (below main) (in /lib64/libc-2.12.so) ==5661== ==5661== ==5661== HEAP SUMMARY: ==5661== in use at exit: 20,711 bytes in 53 blocks ==5661== total heap usage: 596 allocs, 543 frees, 165,648 bytes allocated ==5661== ==5661== 28 bytes in 1 blocks are definitely lost in loss record 3 of 12 ==5661== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==5661== by 0x3E0187F6E1: strdup (in /lib64/libc-2.12.so) ==5661== by 0x3E0301442C: selinux_raw_to_trans_context (in /lib64/libselinux.so.1) ==5661== by 0x3E0300FE69: lgetfilecon (in /lib64/libselinux.so.1) ==5661== by 0x40BDE8: ??? (in /bin/ls) ==5661== by 0x403D7A: ??? (in /bin/ls) ==5661== by 0x408982: ??? (in /bin/ls) ==5661== by 0x3E0181ECDC: (below main) (in /lib64/libc-2.12.so) ==5661== ==5661== 56 bytes in 2 blocks are definitely lost in loss record 8 of 12 ==5661== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==5661== by 0x3E0187F6E1: strdup (in /lib64/libc-2.12.so) ==5661== by 0x3E030144CB: selinux_raw_to_trans_context (in /lib64/libselinux.so.1) ==5661== by 0x3E0300FE69: lgetfilecon (in /lib64/libselinux.so.1) ==5661== by 0x40BDE8: ??? (in /bin/ls) ==5661== by 0x403D7A: ??? (in /bin/ls) ==5661== by 0x408982: ??? (in /bin/ls) ==5661== by 0x3E0181ECDC: (below main) (in /lib64/libc-2.12.so) ==5661== ==5661== LEAK SUMMARY: ==5661== definitely lost: 84 bytes in 3 blocks ==5661== indirectly lost: 0 bytes in 0 blocks ==5661== possibly lost: 0 bytes in 0 blocks ==5661== still reachable: 20,627 bytes in 50 blocks ==5661== suppressed: 0 bytes in 0 blocks ==5661== Reachable blocks (those to which a pointer was found) are not shown. ==5661== To see them, rerun with: --leak-check=full --show-reachable=yes ==5661== ==5661== For counts of detected and suppressed errors, rerun with: -v ==5661== Use --track-origins=yes to see where uninitialised values come from ==5661== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 6 from 6) #
Jim are you sure this is a bug in SELinux. The scon returned by lgetfilecon, needs to be freed with a freecon.
Created attachment 532335 [details] I use this test program and run it through valgrind and shows no leaks.
Hi Dan, Sorry about that. It is indeed a leak in ls.c. I have switched this back to coreutils. This affects upstream coreutils, too, and I've written the patch to fix it there: http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1833
Thanks Jim for upstream fix...
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0933.html