https://bugs.kde.org/show_bug.cgi?id=402833
--- Comment #13 from Olly Betts <ojwbetts+...@gmail.com> --- > Adding a suppression is probably not the answer. I didn't try to claim it was - I explicitly presented it as a way to work around the problem. If I followed the discussion in https://bugs.kde.org/show_bug.cgi?id=453084#c9 the underlying problem is that some of the optimised memcpy() implementations actually support overlapping blocks (i.e. they are also valid memmove() implementations) and for these memmove() and memcpy() both end up using the same function to implement the copy: | The problem is that __memcpy_chk_sse2_unaligned and __memmove_chk_sse2_unaligned are aliases to the same function Due to this valgrind can think the call was to memcpy() when it was actually memmove(). The call stack however shows memmove() so my suppression works. > The question is why Valgrind isn't rediecting the call to memmove? On Linux > the memmove may have been replaced by a call to memcpy if the compiler deems > it safe to do so. That does cause us problems as our checks are more > conservative. AIUI, this is NOT the compiler proving to itself that the source and destination can't overlap and replacing memmove with memcpy, but happens at dynamic link time when a memmove() implementation is selected based on the features supported by the CPU the code is being run on. > What exactly is the error message? ==4137856== Source and destination overlap in memcpy_chk(0x1ffeffb000, 0x1ffeffb010, 10224) ==4137856== at 0x484BE22: __memcpy_chk (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==4137856== by 0x495A87B: memmove (string_fortified.h:36) This really is from a call to memmove(), and one where the source and destination often will overlap (it's copying the tail end of a buffer to the start of that buffer, so it'll overlap when there's more left in the buffer than has been used): n -= (p - buf); memmove(buf, p, n); -- You are receiving this mail because: You are watching all bug changes.
