Valgrind报Invalid read/write时，首要排查栈溢出或越界，常见原因包括数组下标越界、使用已释放堆内存、局部变量地址逃逸；需启用--track-origins=yes并加-g、-O0编译。
Valgrind报Invalid read/write时，先确认是不是栈溢出或越界
这类错误最常见的是数组下标越界、使用了已释放的堆内存，或者局部变量地址逃逸。Valgrind默认只检测堆内存（malloc/new），但Invalid read of size X也可能是栈上越界——比如char buf[10]; strcpy(buf, big_str);。这时候要加--tool=memcheck --track-origins=yes，让Valgrind追踪未初始化值的来源，否则容易误判为“野指针”。
- 编译时务必加
-g，否则行号全丢，定位困难 - 禁用编译器优化（
-O0），-O2可能把变量优化进寄存器，Valgrind看不到访问路径 - 如果程序用了
mmap或自定义分配器，需配合--freelist-vol=... --freelist-big-blocks=...调大缓存，否则漏报
遇到Address 0x... is 8 bytes inside a block of size 16 alloc'd说明真越界了
这条信息其实已经告诉你：访问地址在某次malloc返回块的内部偏移8字节处，而该块总共才16字节——也就是说，你读/写了第9~16字节之后的位置（比如索引[16]或[20]）。关键不是看“inside”，而是对比“size”和你代码里实际访问的偏移量。
- 检查所有
for (int i = 0; i 这种 <li>注意<code>std::vector::data()和.size()的配合，别拿vec.data()[vec.size()]当合法地址 - 多线程场景下，这个错误可能掩盖真正的竞态：一个线程刚
delete，另一个线程立刻读，Valgrind会报Invalid read而非use-after-free（后者需要--tool=helgrind）
Use of uninitialised value of size 8常被当成指针问题，其实是整数/浮点参与了条件判断
这个错误不一定是空指针解引用。比如int x; if (x > 0) { ... }，x未初始化就参与比较，Valgrind就会报出来。64位系统上size 8大概率是long、size_t或指针类型，但根源是“用了没赋值的变量”，不是内存损坏。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 结构体成员未显式初始化（尤其含
uint64_t、double等非零默认值的字段） -
new T[]不会调用构造函数，T是POD类型时整个数组都是未初始化的 - 用
memset(&obj, 0, sizeof(obj))看似清零，但对含虚函数或非平凡构造的类是UB，Valgrind可能后续报一堆衍生错误
Linux下跑Valgrind卡死或报Can't attach to process？检查ptrace权限和seccomp
容器环境（Docker/K8s）或启用了seccomp策略的系统，会禁止ptrace系统调用，而Valgrind依赖它注入检测逻辑。此时不是你的代码有问题，而是运行环境拦住了工具本身。
立即学习“C++免费学习笔记（深入）”；
- Docker启动时加
--cap-add=SYS_PTRACE，否则valgrind ./a.out直接失败 - 某些发行版（如Ubuntu 22.04+）默认开启
kernel.yama.ptrace_scope=2，需临时改回0：sudo sysctl -w kernel.yama.ptrace_scope=0 - 如果程序自己调用了
prctl(PR_SET_NO_NEW_PRIVS, 1)或seccomp过滤了ptrace，Valgrind必然失败，只能换到开发机上跑
Valgrind的报错行号和上下文基本可靠，但它的“推测”能力有限——比如把两次不同malloc的块搞混，或在内联函数展开后丢失原始调用链。真遇到绕不开的误报，优先怀疑是否用了__builtin_assume、__attribute__((may_alias))这类打破别名规则的写法。
