code： #include<stdlib.h> #include<malloc.h> #include<string.h> void test() { int *p = malloc(sizeof(int)*10); p[10] = 7; memcpy(p+1, p, 5); free(p); free(p); int *p1; p1 = 1; } int main(void) { test(); return 0; } OBSERVED RESULT ==6356== Memcheck, a memory error detector ==6356== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==6356== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==6356== Command: ./test ==6356== ==6356== Invalid write of size 4 ==6356== at 0x1091AB: test (in /home/alwyn/文档/test) ==6356== by 0x109201: main (in /home/alwyn/文档/test) ==6356== Address 0x4a51068 is 0 bytes after a block of size 40 alloc'd ==6356== at 0x483B7FB: malloc (vg_replace_malloc.c:307) ==6356== by 0x10919E: test (in /home/alwyn/文档/test) ==6356== by 0x109201: main (in /home/alwyn/文档/test) ==6356== ==6356== Invalid free() / delete / delete[] / realloc() ==6356== at 0x483C9FC: free (vg_replace_malloc.c:538) ==6356== by 0x1091E4: test (in /home/alwyn/文档/test) ==6356== by 0x109201: main (in /home/alwyn/文档/test) ==6356== Address 0x4a51040 is 0 bytes inside a block of size 40 free'd ==6356== at 0x483C9FC: free (vg_replace_malloc.c:538) ==6356== by 0x1091D8: test (in /home/alwyn/文档/test) ==6356== by 0x109201: main (in /home/alwyn/文档/test) ==6356== Block was alloc'd at ==6356== at 0x483B7FB: malloc (vg_replace_malloc.c:307) ==6356== by 0x10919E: test (in /home/alwyn/文档/test) ==6356== by 0x109201: main (in /home/alwyn/文档/test) ==6356== ==6356== ==6356== HEAP SUMMARY: ==6356== in use at exit: 0 bytes in 0 blocks ==6356== total heap usage: 1 allocs, 2 frees, 40 bytes allocated ==6356== ==6356== All heap blocks were freed -- no leaks are possible ==6356== ==6356== For lists of detected and suppressed errors, rerun with: -s ==6356== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) EXPECTED RESULT ==28293== Invalid write of size 4 ==28293== at 0x8048498: test (in /home/ken/work/test) ==28293== by 0x80484E6: main (in /home/ken/work/test) ==28293== Address 0x41fe050 is 0 bytes after a block of size 40 alloc'd ==28293== at 0x402A298: malloc (vg_replace_malloc.c:299) ==28293== by 0x804848E: test (in /home/ken/work/test) ==28293== by 0x80484E6: main (in /home/ken/work/test) ==28293== ==28293== Source and destination overlap in memcpy(0x41fe02c, 0x41fe028, 5) ==28293== at 0x402E943: memcpy (vg_replace_strmem.c:1019) ==28293== by 0x80484BA: test (in /home/ken/work/test) ==28293== by 0x80484E6: main (in /home/ken/work/test) ==28293== ==28293== Invalid free() / delete / delete[] / realloc() ==28293== at 0x402B305: free (vg_replace_malloc.c:530) ==28293== by 0x80484D0: test (in /home/ken/work/test) ==28293== by 0x80484E6: main (in /home/ken/work/test) ==28293== Address 0x41fe028 is 0 bytes inside a block of size 40 free'd ==28293== at 0x402B305: free (vg_replace_malloc.c:530) ==28293== by 0x80484C5: test (in /home/ken/work/test) ==28293== by 0x80484E6: main (in /home/ken/work/test) ==28293== Block was alloc'd at ==28293== at 0x402A298: malloc (vg_replace_malloc.c:299) ==28293== by 0x804848E: test (in /home/ken/work/test) ==28293== by 0x80484E6: main (in /home/ken/work/test) ==28293== ==28293== Use of uninitialised value of size 4 ==28293== at 0x80484D4: test (in /home/ken/work/test) ==28293== by 0x80484E6: main (in /home/ken/work/test) ==28293== ==28293== ==28293== Process terminating with default action of signal 11 (SIGSEGV) ==28293== Bad permissions for mapped region at address 0x40804AD ==28293== at 0x80484D4: test (in /home/ken/work/test) ==28293== by 0x80484E6: main (in /home/ken/work/test) ==28293== ==28293== HEAP SUMMARY: ==28293== in use at exit: 0 bytes in 0 blocks ==28293== total heap usage: 1 allocs, 2 frees, 40 bytes allocated ==28293== ==28293== All heap blocks were freed -- no leaks are possible ==28293== ==28293== For counts of detected and suppressed errors, rerun with: -v ==28293== Use --track-origins=yes to see where uninitialised values come from ==28293== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Ubuntu20.04 ADDITIONAL INFORMATION
Works fine for me. How did you build your program? Did you statically link it or something?
Hmm no it doesn't, which is very odd.
(In reply to Tom Hughes from comment #2) > Hmm no it doesn't, which is very odd. When I used memcheck for the first time, I tested this code, and the result was the expected result I submitted, but it couldn't be detected after a few days. This is strange. I tried to solve it for a while but failed.
It seems we are misidentifying memcpy (which is actually memcpy@GLIBC_2.14) as memcpy@GLIBC_2.2.5 which is the old version that actually had memmove semantics.
I think what's happening is that depending on the CPU architecture the IFUNC is sometimes resolving the memcpy call to the memmove implementation which then makes us treat it as memmove.
(In reply to Tom Hughes from comment #5) > I think what's happening is that depending on the CPU architecture the IFUNC > is sometimes resolving the memcpy call to the memmove implementation which > then makes us treat it as memmove. How should I solve it, or can this be solved？
I think this is a duplicate of https://bugs.kde.org/show_bug.cgi?id=402833