valgrind 报错定位到 malloc/free 等系统函数内部，说明问题不在库函数本身，而在调用方传入非法参数或内存状态异常；真正错误源头需结合调用栈和 --track-origins=yes 追溯至用户代码行，如 malloc 后未初始化即使用、重复 free、栈地址误 free、new/delete 不匹配等。
Valgrind 报错定位到 malloc、free 或系统库函数内部怎么办
Valgrind 显示错误发生在 malloc、free、memcpy 等库函数内部，不是你代码写错了，而是你传给它们的参数或内存状态不合法。它只是“暴露点”，真正的问题在调用方。
为什么 Invalid write 会指向 memcpy 而不是你的代码行
因为 Valgrind 的检测逻辑是：当某次内存操作（如 memcpy）触发非法访问时，它记录的是出错指令所在的函数——而 memcpy 是执行者，不是责任方。真正的越界源头是你传给它的 src 或 dst 地址，或者 n 参数超出了实际可用长度。
- 检查调用
memcpy前后，src和dst指针是否有效（非 NULL、未释放、未越界） - 确认
n是否小于等于源缓冲区大小，且不超过目标缓冲区容量 - 注意：如果源或目标来自
malloc分配但未初始化，memcpy本身不会报uninitialised，但后续读取可能触发 —— 此时要加--track-origins=yes
--track-origins=yes 必须开，否则找不到真正源头
默认情况下，Valgrind 对 Use of uninitialised value 类错误只报出错位置，不追溯变量第一次被读取未初始化的来源。加上这个选项后，它会多花 10–20% 时间，但能输出类似这样的关键线索：
==12345== Use of uninitialised value of size 8 ==12345== at 0x4C30F6E: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==12345== by 0x4006B7: main (example.c:15) ==12345== Uninitialised value was created by a heap allocation ==12345== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==12345== by 0x4006A1: main (example.c:12)
看到最后一行 example.c:12 才是真正问题所在：你在第 12 行 malloc 后没初始化，却在第 15 行直接传给 strcpy。
遇到 free 报 Invalid free 或 double free 怎么回溯
这类错误几乎总是源于指针管理混乱，而不是 free 自身有问题。重点排查以下情况：
- 同一指针被
free两次：检查是否在多个分支、异常路径或析构逻辑中重复释放 - 释放了栈上变量地址（如
int buf[10]; free(buf);）：Valgrind 会明确提示Address is on stack - 释放了常量字符串地址（如
char *p = "hello"; free(p);）：错误信息含Address is in a r-x mapped file - 释放前指针已被改写（如数组越界覆盖了相邻指针变量）：此时需结合
--vgdb-error=0配合 GDB 动态调试
最易被忽略的是：C++ 中混用 new/delete 和 malloc/free，或数组 new new[] 却用 delete（非 delete[]）释放 —— Valgrind 会报 Mismatched free() / delete / delete []，必须严格匹配。
