glibc-2.13.90-11.x86_64's memcpy/memmove seem to be doing 8-byte copies in some situations where there are fewer than 8 bytes left in the source buffer. Eg, running "valgrind epiphany", you see lots of: ==326== Invalid read of size 8 ==326== at 0x31A9B35BD0: __memcpy_ssse3_back (memcpy-ssse3-back.S:513) ... ==326== Address 0xcabd658 is 424 bytes inside a block of size 431 alloc'd ==326== at 0x4A0640D: malloc (vg_replace_malloc.c:236) and ==326== Invalid read of size 8 ==326== at 0x31A9B3AC68: __memmove_ssse3_back (memcpy-ssse3-back.S:236) ... ==326== Address 0x1643ca78 is 1,592 bytes inside a block of size 1,599 alloc'd ==326== at 0x4A064F2: realloc (vg_replace_malloc.c:525) etc On F14, with glibc-2.13-1.x86_64, and building the same version of epiphany and other GNOME dependencies by hand, these warnings do not appear. I haven't been able to come up with a trivial test case.
This is a false positive, the address is correctly aligned.
I'm pretty sure it's not claiming incorrect alignment, it's claiming that glibc is doing an (aligned) 8-byte read when there are only 7 bytes left in the buffer, and so it is reading 1 byte beyond the end of the buffer.
There is nothing wrong in reading that 1 byte beyond the end of the buffer, if you know the read won't trap because of that and if you don't actualy use it. valgrind overrides glibc's memmove (and many other functions) though, so it is strange that glibc memmove has been called.
Created attachment 503686 [details] seward suggests this as a quick-fix to make valgrind usable again
I don't think the patch is correct, after all there are 3 different memmove implementations. As it worked in F14 and valgrind already has IFUNC support, I bet this is related to the glibc workaround for lame apps. readelf -Ws /lib64/libc.so.6 | grep 'memcpy\|memmove' | grep -v 'LOCAL\|wmem\|_chk' 1103: 00000035e7a83160 71 IFUNC GLOBAL DEFAULT 12 memcpy.5 1104: 00000035e7a88d40 60 IFUNC GLOBAL DEFAULT 12 memcpy@@GLIBC_2.14 1944: 00000035e7a83160 71 IFUNC GLOBAL DEFAULT 12 memmove@@GLIBC_2.2.5 5575: 00000035e7a83160 71 IFUNC GLOBAL DEFAULT 12 memcpy.5 6284: 00000035e7a83160 71 IFUNC GLOBAL DEFAULT 12 memmove 7443: 00000035e7a88d40 60 IFUNC GLOBAL DEFAULT 12 memcpy@@GLIBC_2.14 shows that in glibc 2.14+ memcpy.5 is IFUNC aliased to memmove, while memcpy@@GLIBC_2.14 is a real memcpy (again, IFUNC).
Well, we could stick in the other two implementation too. The crucial bit for me is that locally I get sane useful results out of valgrind again.
Please try rawhide valgrind (3.6.1-4.fc16), if that works, will build the same for f15 updates-testing too.
valgrind-3.6.1-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/valgrind-3.6.1-4.fc15
Package valgrind-3.6.1-4.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing valgrind-3.6.1-4.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/valgrind-3.6.1-4.fc15 then log in and leave karma (feedback).
It solves that. I do however get new warnings of... ==6241== Conditional jump or move depends on uninitialised value(s) ==6241== at 0x3771217476: index (strchr.S:56) ==6241== by 0x37712078F2: expand_dynamic_string_token (dl-load.c:326) ==6241== by 0x3771208241: _dl_map_object (dl-load.c:2193) ==6241== by 0x37712017DD: map_doit (rtld.c:629) ==6241== by 0x377120E8A5: _dl_catch_error (dl-error.c:178) ==6241== by 0x3771200F16: do_preload (rtld.c:813) ==6241== by 0x37712048A0: dl_main (rtld.c:1696) ==6241== by 0x3771214F83: _dl_sysdep_start (dl-sysdep.c:244) ==6241== by 0x377120512E: _dl_start (rtld.c:334) ==6241== by 0x3771201607: ??? (in /lib64/ld-2.13.90.so) ==6241== by 0x1: ??? ==6241== by 0x7FEFFD496: ??? ==6241== by 0x7FEFFD4BA: ??? ==6241== ==6241== Conditional jump or move depends on uninitialised value(s) ==6241== at 0x377121747B: index (strchr.S:59) ==6241== by 0x37712078F2: expand_dynamic_string_token (dl-load.c:326) ==6241== by 0x3771208241: _dl_map_object (dl-load.c:2193) ==6241== by 0x37712017DD: map_doit (rtld.c:629) ==6241== by 0x377120E8A5: _dl_catch_error (dl-error.c:178) ==6241== by 0x3771200F16: do_preload (rtld.c:813) ==6241== by 0x37712048A0: dl_main (rtld.c:1696) ==6241== by 0x3771214F83: _dl_sysdep_start (dl-sysdep.c:244) ==6241== by 0x377120512E: _dl_start (rtld.c:334) ==6241== by 0x3771201607: ??? (in /lib64/ld-2.13.90.so) ==6241== by 0x1: ??? ==6241== by 0x7FEFFD496: ??? ==6241== by 0x7FEFFD4BA: ???
Forgotten yum update? F14 now has glibc-2.14, instead of glibc-2.13.90.
Ah, indeed. Yup, noiseless now.
valgrind-3.6.1-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.