valgrind memcheck会报告“invalid read/write of size x”，指出读写地址位于同一块已分配内存内且存在交叉，典型表现为在memcpy内部触发非法访问，并定位到用户代码中重叠调用行。
memcpy 重叠时 Valgrind 会报什么
Memcheck 能检测 memcpy、memmove、strcpy 等函数中 src 和 dst 指针重叠却未用 memmove 替代的问题。它不会直接说“你该用 memmove”，而是报告 Invalid read of size X 或 Invalid write of size X，并指出读/写地址落在同一块已分配内存内、且存在交叉——这往往是重叠拷贝的典型痕迹。
怎么复现和确认是 memcpy 重叠导致的
写个最小可复现代码就能验证：
#include <string.h>
#include <stdlib.h>
int main() {
char *p = malloc(10);
strcpy(p, "0123456789");
memcpy(p + 2, p, 8); // 重叠：src=p, dst=p+2, len=8 → 覆盖自身
free(p);
return 0;
}
</stdlib.h></string.h>
编译加 -g 后运行：valgrind --tool=memcheck ./a.out，你会看到类似输出：
==12345== Invalid read of size 1 ==12345== at 0x4C2E0F0: memcpy (vg_replace_strmem.c:1026) ==12345== by 0x4005B6: main (overlap.c:8) ==12345== Address 0x51f0042 is 2 bytes inside a block of size 10 alloc'd ==12345== at 0x4C27BC3: malloc (vg_replace_malloc.c:299) ==12345== by 0x4005A6: main (overlap.c:6)
- 关键线索是
Invalid read发生在memcpy内部，且地址属于同一块malloc出来的内存 - 调用栈指向你代码里那行
memcpy，不是库内部逻辑错乱 - 如果
src和dst差值小于len（比如本例中差 2，len 是 8），基本就是重叠了
为什么不用 memmove 就一定会出问题
memcpy 标准不保证重叠行为，实际实现常按“从低到高”顺序拷贝；一旦 dst 起始地址高于 src 但两者重叠，就会在读完前就把旧数据覆盖掉，导致后续读取的是刚写入的新值而非原始值——结果不可预测，且可能随优化等级、libc 版本变化。
而 memmove 明确要求处理重叠，通常会先判断方向，再决定从高往低或低往高拷贝。所以：
- 只要存在
src和dst可能重叠的场景，一律换用memmove - 不要依赖“这次没崩就没事”——Valgrind 报的
Invalid read/write就是未定义行为已触发的铁证 -
strncpy、snprintf等函数内部若涉及重叠缓冲区操作，同样可能被 Memcheck 捕获，原理一致
容易被忽略的边界情况
重叠不只发生在明显偏移时，这些情况也得留心：
-
memcpy(p, p, n)：src == dst，n > 0 → 实际无操作，但 Valgrind 可能不报（取决于版本），不代表安全 - 结构体内字段地址计算错误，比如
memcpy(&s.a, &s.b, sizeof(s.a))，若a和b在内存中相邻且类型大小不同，可能意外重叠 - 使用
std::copy或std::vector::assign时传入同一容器的迭代器区间（如v.assign(v.begin()+1, v.end())），底层可能调用memcpy，同样适用此规则 - 第三方库函数（如某些图像处理函数）内部做内存搬移，若你传入重叠 buffer，Valgrind 仍能捕获，但调用栈会更深，需结合
--track-origins=yes追到你的传参点
真正麻烦的不是报错本身，而是重叠发生在深层调用链里，且只在特定输入下触发——这时候 --track-origins=yes 和完整调试符号缺一不可。
