Hide Forgot
Description of problem: Running ls -l within valgrind reports uninitialised values. Version-Release number of selected component (if applicable): coreutils-8.4-13.el6.x86_64 How reproducible: always Steps to Reproduce: 1. log to x86_64 machine 2. run "valgrind ls -l" Actual results: ==8525== Memcheck, a memory error detector ==8525== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==8525== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==8525== Command: ls -l ==8525== ==8525== Conditional jump or move depends on uninitialised value(s) ==8525== at 0x52D7C9B: __GI___strcasecmp_l (in /lib64/libc-2.12.so) ==8525== by 0x5273E84: __gconv_open (in /lib64/libc-2.12.so) ==8525== by 0x5281417: _nl_find_msg (in /lib64/libc-2.12.so) ==8525== by 0x5281BE3: __dcigettext (in /lib64/libc-2.12.so) ==8525== by 0x409CA3: ??? (in /bin/ls) ==8525== by 0x5272C9C: (below main) (in /lib64/libc-2.12.so) ==8525== ==8525== Use of uninitialised value of size 8 ==8525== at 0x52D9DD4: __GI___strcasecmp_l (in /lib64/libc-2.12.so) ==8525== by 0x5273E84: __gconv_open (in /lib64/libc-2.12.so) ==8525== by 0x5281417: _nl_find_msg (in /lib64/libc-2.12.so) ==8525== by 0x5281BE3: __dcigettext (in /lib64/libc-2.12.so) ==8525== by 0x409CA3: ??? (in /bin/ls) ==8525== by 0x5272C9C: (below main) (in /lib64/libc-2.12.so) ==8525== ==8525== Use of uninitialised value of size 8 ==8525== at 0x52D9DD8: __GI___strcasecmp_l (in /lib64/libc-2.12.so) ==8525== by 0x5273E84: __gconv_open (in /lib64/libc-2.12.so) ==8525== by 0x5281417: _nl_find_msg (in /lib64/libc-2.12.so) ==8525== by 0x5281BE3: __dcigettext (in /lib64/libc-2.12.so) ==8525== by 0x409CA3: ??? (in /bin/ls) ==8525== by 0x5272C9C: (below main) (in /lib64/libc-2.12.so) ==8525== total 0 ==8525== ==8525== HEAP SUMMARY: ==8525== in use at exit: 19,312 bytes in 3 blocks ==8525== total heap usage: 137 allocs, 134 frees, 65,755 bytes allocated ==8525== ==8525== LEAK SUMMARY: ==8525== definitely lost: 0 bytes in 0 blocks ==8525== indirectly lost: 0 bytes in 0 blocks ==8525== possibly lost: 0 bytes in 0 blocks ==8525== still reachable: 19,312 bytes in 3 blocks ==8525== suppressed: 0 bytes in 0 blocks ==8525== Rerun with --leak-check=full to see details of leaked memory ==8525== ==8525== For counts of detected and suppressed errors, rerun with: -v ==8525== Use --track-origins=yes to see where uninitialised values come from ==8525== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 6 from 6) Expected results: no uninitialised values
Trace with enabled debuginfo - these uninitialized value(s) reports are only on x86_64 arch. ==17674== Conditional jump or move depends on uninitialised value(s) ==17674== at 0x3C7A285900: __GI___strcasecmp_l (strcmp.S:1998) ==17674== by 0x3C7A21FE24: __gconv_open (gconv_open.c:70) ==17674== by 0x3C7A22D3B7: _nl_find_msg (dcigettext.c:974) ==17674== by 0x3C7A22DB83: __dcigettext (dcigettext.c:640) ==17674== by 0x409CA3: main (ls.c:2063) ==17674== Uninitialised value was created by a stack allocation ==17674== at 0x3C7A21FD8F: __gconv_open (gconv_open.c:65) ==17674== ==17674== Use of uninitialised value of size 8 ==17674== at 0x3C7A285D24: __GI___strcasecmp_l (strcmp.S:2257) ==17674== by 0x3C7A21FE24: __gconv_open (gconv_open.c:70) ==17674== by 0x3C7A22D3B7: _nl_find_msg (dcigettext.c:974) ==17674== by 0x3C7A22DB83: __dcigettext (dcigettext.c:640) ==17674== by 0x409CA3: main (ls.c:2063) ==17674== Uninitialised value was created by a stack allocation ==17674== at 0x3C7A21FD8F: __gconv_open (gconv_open.c:65) ==17674== ==17674== Use of uninitialised value of size 8 ==17674== at 0x3C7A285D28: __GI___strcasecmp_l (strcmp.S:2258) ==17674== by 0x3C7A21FE24: __gconv_open (gconv_open.c:70) ==17674== by 0x3C7A22D3B7: _nl_find_msg (dcigettext.c:974) ==17674== by 0x3C7A22DB83: __dcigettext (dcigettext.c:640) ==17674== by 0x409CA3: main (ls.c:2063) ==17674== Uninitialised value was created by a stack allocation ==17674== at 0x3C7A21FD8F: __gconv_open (gconv_open.c:65) ==17674== So - the problematic line is char const *locale_format = dcgettext (NULL, long_time_format[i], LC_TIME); long_time_format array is global variable and is defined ... LC_TIME is checked above ... I think this is false positive caused by glibc optimalizations ... could be probably added to valgrind suppressions - if you are worried about this output.