[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 Mark Wielaard changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #10 from Mark Wielaard --- (In reply to mliska from comment #1) > May be related to PR402833. Yes, it is, both are about the valgrind ifunc resolver aliasing two memcpy/memmove variants, causing the memmove variant to trigger the overlap check (or the other way around, the memcpy variant not triggering the overlap check as it should). *** This bug has been marked as a duplicate of bug 402833 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 Sam James changed: What|Removed |Added CC||s...@gentoo.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- Well which function did the compiler actually use for that? It doesn't really matter what you wrote in the source - if the compiler has decided that it's safe to replace it with memcpy (because it knows the memcpy implementation is overlap safe) then it might do that but valgrind has no way to know that so will warn about it. I'd try and reproduce it to see for myself but it's likely to be very environment sensitive and you haven't even said what version of Fedora you're using. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084
--- Comment #3 from mli...@suse.cz ---
(In reply to Tom Hughes from comment #2)
> Well which function did the compiler actually use for that?
>
> It doesn't really matter what you wrote in the source - if the compiler has
> decided that it's safe to replace it with memcpy (because it knows the
> memcpy implementation is overlap safe) then it might do that but valgrind
> has no way to know that so will warn about it.
No, it's not the case:
$ objdump -S ./a.out
...
int main() {
201146: 55 push %rbp
201147: 48 89 e5mov%rsp,%rbp
...
201176: e8 95 fe ff ff call 201010 <__memmove_chk@plt>
>
> I'd try and reproduce it to see for myself but it's likely to be very
> environment sensitive and you haven't even said what version of Fedora
> you're using.
Fedora 35 (latest), please see the provided Dockerfile.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 --- Comment #5 from Tom Hughes --- Sorry I meant I reproduced in Fedora 35 and without having to figure out docker which is a totally unnecessary distraction. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 Siddhesh Poyarekar changed: What|Removed |Added CC||siddh...@gotplt.org --- Comment #9 from Siddhesh Poyarekar --- (In reply to Tom Hughes from comment #6) > In this case it chose __memcpy_chk_sse2_unaligned presumably because it > knows that is in fact overlap safe, so as far as valgrind is concerned the > call did in fact wind up going to memcpy and hence got checked. The problem is that __memcpy_chk_sse2_unaligned and __memmove_chk_sse2_unaligned are aliases to the same function: ``` $ nm /lib64/libc.so.6 | grep "__mem\(cpy\|move\)_chk_sse2_unaligned$" 000b9c50 t __memcpy_chk_sse2_unaligned 000b9c50 t __memmove_chk_sse2_unaligned ``` Maybe valgrind could see if the function has a *memmove* alias before it triggers the warning? (In reply to mliska from comment #7) > Are you sure about it? If I use gdb, then it's resolved to the following > function: > > Breakpoint 1, __memmove_chk_avx_unaligned () at > ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:206 > 206 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Directory not > empty. Again, the memcpy and memmove variants are aliases and one just happened to be selected over another, or maybe gdb has some smarts to make it happen, I don't know: ``` $ nm /lib64/libc.so.6 | grep "__mem\(cpy\|move\)_chk_avx_unaligned$" 001828a0 t __memcpy_chk_avx_unaligned 001828a0 t __memmove_chk_avx_unaligned ``` -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 --- Comment #8 from mli...@suse.cz --- > In this case it chose __memcpy_chk_sse2_unaligned presumably because it > knows that is in fact overlap safe Note that ifunc resolver does not operate on the actual arguments (of the first invocation). So it cannot assume that an overlap is safe. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 --- Comment #7 from mli...@suse.cz --- > So __memmove_chk is actually an IFUNC that, on first call, resolves to the > optimal implementation for the current preprocessor. > > In this case it chose __memcpy_chk_sse2_unaligned presumably because it > knows that is in fact overlap safe, so as far as valgrind is concerned the > call did in fact wind up going to memcpy and hence got checked. Are you sure about it? If I use gdb, then it's resolved to the following function: Breakpoint 1, __memmove_chk_avx_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:206 206 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Directory not empty. (gdb) bt #0 __memmove_chk_avx_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:206 #1 0x0040069b in main () at drpm.c:8 which is proved if I put breakpoint to __memmove_chk_ifunc: │ > 0x77e1ed50 <__memmove_chk_ifunc+290>ret (gdb) p /x $rax $2 = 0x77e88820 (gdb) p & __memmove_chk_avx_unaligned $3 = ( *) 0x77e88820 <__memmove_chk_avx_unaligned> -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 --- Comment #4 from Tom Hughes --- I've managed to reproduce it on Fedora 34 and it does seem to be linked to use __memmove_chk and __memmove_chk and __memcpy_chkdo seem to be different symbols in glibc (sometimes the two are the same if memcpy is known to be overlap safe) so it does seem a bit odd. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 mli...@suse.cz changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=402833 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 --- Comment #6 from Tom Hughes --- I think this (from --trace-redir=yes) explains is: --3163534-- REDIR: 0x4a5f6c0 (libc.so.6:__memmove_chk) redirected to 0x48391ea (_vgnU_ifunc_wrapper) --3163534-- Adding redirect for indirect function 0x4a5f6c0 from 0x493ff50 -> 0x484eba0 --3163534-- REDIR: 0x493ff50 (libc.so.6:__memcpy_chk_sse2_unaligned) redirected to 0x484f220 (__memcpy_chk) So __memmove_chk is actually an IFUNC that, on first call, resolves to the optimal implementation for the current preprocessor. In this case it chose __memcpy_chk_sse2_unaligned presumably because it knows that is in fact overlap safe, so as far as valgrind is concerned the call did in fact wind up going to memcpy and hence got checked. I'm not sure there's a huge amount we can do to avoid this sadly. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 mli...@suse.cz changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from mli...@suse.cz --- May be related to PR402833. -- You are receiving this mail because: You are watching all bug changes.
