Description of problem: I don't know that this is a valgrind bug. It may be a glibc bug. I'm hoping for some help to figure out which. I maintain the stp package. It is currently failing to build in Rawhide on x86_64 because its self-tests use valgrind to check for memory leaks, and it is getting this: `which valgrind` --leak-check=full --error-exitcode=10 ./a3.out ==29419== Memcheck, a memory error detector ==29419== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==29419== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==29419== Command: ./a3.out ==29419== ==29419== Conditional jump or move depends on uninitialised value(s) ==29419== at 0x4018426: index (in /usr/lib64/ld-2.18.so) ==29419== by 0x40077A3: expand_dynamic_string_token (in /usr/lib64/ld-2.18.so ) ==29419== by 0x40082D7: _dl_map_object (in /usr/lib64/ld-2.18.so) ==29419== by 0x40013DD: map_doit (in /usr/lib64/ld-2.18.so) ==29419== by 0x400F1A3: _dl_catch_error (in /usr/lib64/ld-2.18.so) ==29419== by 0x4000EBD: do_preload (in /usr/lib64/ld-2.18.so) ==29419== by 0x400405C: dl_main (in /usr/lib64/ld-2.18.so) ==29419== by 0x4016104: _dl_sysdep_start (in /usr/lib64/ld-2.18.so) ==29419== by 0x4004B63: _dl_start (in /usr/lib64/ld-2.18.so) ==29419== by 0x40011F7: ??? (in /usr/lib64/ld-2.18.so) ==29419== ==29419== Conditional jump or move depends on uninitialised value(s) ==29419== at 0x401842B: index (in /usr/lib64/ld-2.18.so) ==29419== by 0x40077A3: expand_dynamic_string_token (in /usr/lib64/ld-2.18.so) ==29419== by 0x40082D7: _dl_map_object (in /usr/lib64/ld-2.18.so) ==29419== by 0x40013DD: map_doit (in /usr/lib64/ld-2.18.so) ==29419== by 0x400F1A3: _dl_catch_error (in /usr/lib64/ld-2.18.so) ==29419== by 0x4000EBD: do_preload (in /usr/lib64/ld-2.18.so) ==29419== by 0x400405C: dl_main (in /usr/lib64/ld-2.18.so) ==29419== by 0x4016104: _dl_sysdep_start (in /usr/lib64/ld-2.18.so) ==29419== by 0x4004B63: _dl_start (in /usr/lib64/ld-2.18.so) ==29419== by 0x40011F7: ??? (in /usr/lib64/ld-2.18.so) ==29419== testing getBVUnsignedLongLong function: f0000000effff000 testing getBVUnsignedLongLong function: f0000000effff000 testing getBVUnsignedLongLong function: f0000000effff000 ==29419== ==29419== HEAP SUMMARY: ==29419== in use at exit: 0 bytes in 0 blocks ==29419== total heap usage: 365 allocs, 365 frees, 137,323 bytes allocated ==29419== ==29419== All heap blocks were freed -- no leaks are possible ==29419== ==29419== For counts of detected and suppressed errors, rerun with: -v ==29419== Use --track-origins=yes to see where uninitialised values come from ==29419== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) Is this a missing suppression or an actual bug in glibc? Version-Release number of selected component (if applicable): valgrind-3.8.1-25.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. fedpkg clone stp 2. cd stp 3. fedpkg srpm 4. mock -r fedora-rawhide-x86_64 --rebuild stp-0.1-16.20130223svn.fc20.src.rpm Actual results: The build fails with a valgrind error. Expected results: Successful build. Additional info:
Looks like rawhide switched to glibc-2.18 but the valgrind suppressions and overrides are still for glibc-2.17. Yep. glibc.spec has: * Fri Aug 16 2013 Siddhesh Poyarekar <siddhesh> - 2.18-1 - Upstream release 2.18. hmmm, upstream valgrind apparently hasn't been build against glibc 2.18 yet. I'll investigate what is necessary. Probably not much.
Please try valgrind-3.8.1-26.fc21 * Wed Aug 21 2013 Mark Wielaard <mjw> - 3.8.1-26 - Allow building against glibc 2.18. (#999169)
Yes, that worked. Thank you very much for the quick fix.
Except now it is broken again in nearly the same way. Doing this today: mock -r fedora-rawhide-x86_64 --rebuild stp-0.1-16.20130223svn.fc21.src.rpm results in a test failure like this: ==22918== Memcheck, a memory error detector ==22918== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==22918== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==22918== Command: ./a3.out ==22918== ==22918== Use of uninitialised value of size 8 ==22918== at 0x401953D: index (in /usr/lib64/ld-2.18.90.so) ==22918== by 0x4007DAD: expand_dynamic_string_token (in /usr/lib64/ld-2.18.90.so) ==22918== by 0x400886F: _dl_map_object (in /usr/lib64/ld-2.18.90.so) ==22918== by 0x400142D: map_doit (in /usr/lib64/ld-2.18.90.so) ==22918== by 0x400FA93: _dl_catch_error (in /usr/lib64/ld-2.18.90.so) ==22918== by 0x4001009: do_preload (in /usr/lib64/ld-2.18.90.so) ==22918== by 0x4004440: dl_main (in /usr/lib64/ld-2.18.90.so) ==22918== by 0x4016F34: _dl_sysdep_start (in /usr/lib64/ld-2.18.90.so) ==22918== by 0x4004CF7: _dl_start (in /usr/lib64/ld-2.18.90.so) ==22918== by 0x4001247: ??? (in /usr/lib64/ld-2.18.90.so) ==22918== testing getBVUnsignedLongLong function: f0000000effff000 testing getBVUnsignedLongLong function: f0000000effff000 testing getBVUnsignedLongLong function: f0000000effff000 ==22918== ==22918== HEAP SUMMARY: ==22918== in use at exit: 0 bytes in 0 blocks ==22918== total heap usage: 365 allocs, 365 frees, 137,323 bytes allocated ==22918== ==22918== All heap blocks were freed -- no leaks are possible ==22918== ==22918== For counts of detected and suppressed errors, rerun with: -v ==22918== Use --track-origins=yes to see where uninitialised values come from ==22918== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1) make[1]: *** [3] Error 10 make[1]: Leaving directory `/builddir/build/BUILD/stp-0.1/tests/c-api-tests' make: *** [baseTest] Error 1 So the error is slightly different, but still seems to be the same code. Thoughts?
I do think it is a different issue, even though it appears in the same place. It doesn't happen with upstream (svn) valgrind. I haven't tracked down which specific patch fixed it though.
My current guess is that it is this: https://bugs.kde.org/show_bug.cgi?id=308627 Will try to isolate it. Might be tricky to backport though, if this is the issue.
Thanks once again for an extremely prompt reply, Mark. Do you want me to open a new bug, or just use this one?
(In reply to Jerry James from comment #7) > Thanks once again for an extremely prompt reply, Mark. Do you want me to > open a new bug, or just use this one? A new one might be better, since this one was already used by for the 3.8.1-26 release, which does work fine on f20, just not on rawhide/f21.
It is bug 1011713. I will return this bug to its blissfully closed state.