Description of problem: The pre release of binutils 2.31 (binutils-2.30.90-1.fc29) changed output of valgrind errors and thus also generated suppression. Maybe it is not a bug in binutils itself and valgrind need to leverage new features but I was able to bisect the change to update of the pacakge binutils. Version-Release number of selected component (if applicable): [build@8fa63e16699c ]$ rpm -q binutils binutils-2.30.90-3.fc29.x86_64 How reproducible: Deterministic Steps to Reproduce: 1. dnf install -y gcc binutils valgrind 2. // compile attached file gcc -g -o test test.c 3. valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --gen-suppressions=all --track-origins=yes ./test Actual results: [build@8fa63e16699c ]$ rpm -q binutils binutils-2.30.90-3.fc29.x86_64 [build@8fa63e16699c ]$ gcc -g -o test test.c [build@8fa63e16699c ]$ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --gen-suppressions=all --track-origins=yes ./test |& tail -n40 ==339== by 0x4E94D79: printf (in /usr/lib64/libc-2.27.9000.so) ==339== by 0x401196: ??? (in /home/build/sssd/test) ==339== by 0x4011FA: ??? (in /home/build/sssd/test) ==339== by 0x40122F: ??? (in /home/build/sssd/test) ==339== by 0x40127B: ??? (in /home/build/sssd/test) ==339== by 0x401297: ??? (in /home/build/sssd/test) ==339== by 0x4E5F3B2: (below main) (in /usr/lib64/libc-2.27.9000.so) ==339== Uninitialised value was created by a heap allocation ==339== at 0x4C2FB5B: malloc (vg_replace_malloc.c:299) ==339== by 0x40117B: ??? (in /home/build/sssd/test) ==339== by 0x4011FA: ??? (in /home/build/sssd/test) ==339== by 0x40122F: ??? (in /home/build/sssd/test) ==339== by 0x40127B: ??? (in /home/build/sssd/test) ==339== by 0x401297: ??? (in /home/build/sssd/test) ==339== by 0x4E5F3B2: (below main) (in /usr/lib64/libc-2.27.9000.so) ==339== { <insert_a_suppression_name_here> Memcheck:Cond fun:vfprintf fun:printf obj:/home/build/sssd/test obj:/home/build/sssd/test obj:/home/build/sssd/test obj:/home/build/sssd/test obj:/home/build/sssd/test fun:(below main) } 0 0 0 ==339== ==339== HEAP SUMMARY: ==339== in use at exit: 0 bytes in 0 blocks ==339== total heap usage: 3 allocs, 3 frees, 4,140 bytes allocated ==339== ==339== All heap blocks were freed -- no leaks are possible ==339== ==339== For counts of detected and suppressed errors, rerun with: -v ==339== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 0 from 0) Expected results: //functions names are visible in output; the same as with older version of binutils [build@8fa63e16699c ]$ rpm -q binutils binutils-2.30-26.fc29.x86_64 [build@8fa63e16699c ]$ gcc -g -o test test.c [build@8fa63e16699c sssd]$ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --gen-suppressions=all --track-origins=yes ./test //snip ==297== Conditional jump or move depends on uninitialised value(s) ==297== at 0x4E8CAAD: vfprintf (in /usr/lib64/libc-2.27.9000.so) ==297== by 0x4E94D79: printf (in /usr/lib64/libc-2.27.9000.so) ==297== by 0x4006C6: test_1 (test.c:26) ==297== by 0x40072A: test_3 (test.c:39) ==297== by 0x40075F: test_4 (test.c:53) ==297== by 0x4007AB: test_7 (test.c:65) ==297== by 0x4007C7: main (test.c:72) ==297== Uninitialised value was created by a heap allocation ==297== at 0x4C2FB5B: malloc (vg_replace_malloc.c:299) ==297== by 0x4006AB: test_1 (test.c:25) ==297== by 0x40072A: test_3 (test.c:39) ==297== by 0x40075F: test_4 (test.c:53) ==297== by 0x4007AB: test_7 (test.c:65) ==297== by 0x4007C7: main (test.c:72) ==297== { <insert_a_suppression_name_here> Memcheck:Cond fun:vfprintf fun:printf fun:test_1 fun:test_3 fun:test_4 fun:test_7 fun:main } 0 0 0 ==297== ==297== HEAP SUMMARY: ==297== in use at exit: 0 bytes in 0 blocks ==297== total heap usage: 3 allocs, 3 frees, 4,140 bytes allocated ==297== ==297== All heap blocks were freed -- no leaks are possible ==297== ==297== For counts of detected and suppressed errors, rerun with: -v ==297== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 0 from 0) Additional info: BTW it break all existing valgrind suppression files. Whic is huge disadvantage.
BTW description of ticket used older version of glibc which used older version of binutils at built time in koji (glibc-2.27.9000-35.fc29.x86_64) Output is much worse with latest build of glibc in koji. And it would be simmilar with other libraries which used binutils-2.30.90* in buildroot. BTW I noticed it 1st time in debian unstable https://packages.debian.org/sid/binutils with 2.30.90.20180710-1. But I did not have a time to file a debian bug (But maybe it will help to reduce a scope) [build@8fa63e16699c ]$ rpm -q glibc binutils glibc-2.27.9000-38.fc29.x86_64 binutils-2.30.90-3.fc29.x86_64 [build@8fa63e16699c ]$ gcc -g -o test test.c [build@8fa63e16699c ]$ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --gen-suppressions=all --track-origins=yes ./test //snip ==396== Conditional jump or move depends on uninitialised value(s) ==396== at 0x4C9C7DD: ??? (in /usr/lib64/libc-2.27.9000.so) ==396== by 0x4CA4AA9: ??? (in /usr/lib64/libc-2.27.9000.so) ==396== by 0x401297: ??? (in /home/build/sssd/test) ==396== by 0x4C6F0E2: ??? (in /usr/lib64/libc-2.27.9000.so) ==396== Uninitialised value was created by a stack allocation ==396== at 0x401156: ??? (in /home/build/sssd/test) ==396== { <insert_a_suppression_name_here> Memcheck:Cond obj:/usr/lib64/libc-2.27.9000.so obj:/usr/lib64/libc-2.27.9000.so obj:/home/build/sssd/test obj:/usr/lib64/libc-2.27.9000.so } 0 1094795585 ==396== ==396== HEAP SUMMARY: ==396== in use at exit: 0 bytes in 0 blocks ==396== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==396== ==396== All heap blocks were freed -- no leaks are possible ==396== ==396== For counts of detected and suppressed errors, rerun with: -v ==396== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
Created attachment 1458577 [details] fSource ode for reproducer valgrind errors
Please check if valgrind-3.13.0-21.fc29 fixes this issue.
(In reply to Florian Weimer from comment #3) > Please check if valgrind-3.13.0-21.fc29 fixes this issue. Works well with: binutils-2.30.90-3.fc29.x86_64 valgrind-3.13.0-21.fc29.x86_64
*** This bug has been marked as a duplicate of bug 1600034 ***
(In reply to Lukas Slebodnik from comment #4) > (In reply to Florian Weimer from comment #3) > > Please check if valgrind-3.13.0-21.fc29 fixes this issue. > > Works well with: > binutils-2.30.90-3.fc29.x86_64 > valgrind-3.13.0-21.fc29.x86_64 Thanks for testing. I am glad the fix works.