memcpy不支持内存重叠，重叠时行为未定义；应改用memmove，它通过正向或反向拷贝确保数据安全。
memcpy 重叠报错：Source and destination overlap 是什么
这是 Memcheck 发现你调用了 memcpy（或 memmove、strcpy 等）时，源地址和目标地址发生了重叠，且你没用对函数。C 标准明确规定：memcpy 不保证能正确处理重叠内存区域；它只适用于「不重叠」的拷贝。一旦重叠，行为未定义——可能数据被覆盖、静默错乱、甚至 crash。
为什么 valgrind 能检测到，而程序看起来“还能跑”
因为很多实际场景下，重叠拷贝恰好“碰巧”没出问题（比如小块、特定对齐、编译器优化掩盖），但这是脆弱的依赖。valgrind 在每次 memcpy 调用前检查 src 和 dst 地址范围是否交叉，一发现就报 Source and destination overlap in memcpy(...)。
- 常见触发场景：
memmove(buf + 1, buf, len)（向前移动）、memcpy(buf, buf + 2, len)（向后覆盖） - 注意：
memmove是专门设计来安全处理重叠的，但如果你误写了memcpy，valgrind 就会拦住你 - 不是所有重叠都危险，但所有未定义行为都该消除——尤其在生产环境或跨平台时
怎么改：三步定位 + 替换 + 验证
别只看报错行号，重点确认那行调用是否真需要重叠语义：
- 如果本意就是「移动」（如数组元素前移/后挪），直接把
memcpy换成memmove—— 它语义明确、开销几乎无差别、完全兼容 - 如果本意是「复制一份新数据」，但写错了指针（比如
memcpy(p, p, n)），说明逻辑有误，得查清为何 src == dst，可能是变量未初始化、索引计算错误或条件分支漏处理 - 如果是在操作同一块 buffer 的不同偏移（如解析协议头），确认是否真要覆盖——有时应分配临时 buffer 或用
memmove显式表达意图 - 编译时加
-g，运行 valgrind 时加--num-callers=10 --read-var-info，能帮你看到更清晰的调用栈和变量名
动态库中出现 ??? 行号怎么办
报错堆栈里全是 ???，说明符号信息缺失，valgrind 无法定位到具体 C 源码行。这不是重叠问题本身，而是调试信息没带进去：
- 确保动态库编译时加了
-g，且没执行strip（或打包时保留.debug_*段） - 主程序加载动态库后，**不要调用
dlclose** —— valgrind 在库卸载后会丢弃其 debug info，导致后续泄漏/重叠报错全变??? - 若必须卸载，可临时注释掉
dlclose调用，让库一直活到进程退出，保证符号可用
重叠问题本质是代码逻辑选择错误，不是环境配置问题；但符号缺失会让修复成本翻倍——所以编译选项和生命周期管理，得和代码修改同步处理。
