Valgrind默认不检测普通数组越界，因其memcheck基于内存块有效性而非字节级边界校验；AddressSanitizer才是检测数组越界的事实标准，通过编译插桩实现精准定位。
Valgrind 默认不报数组越界，得换工具或加选项
Valgrind 自带的 memcheck 工具主要检测内存泄漏、使用未初始化内存、释放后使用（use-after-free）等，但对栈上或堆上普通数组的越界读写，默认是不报的。比如 a[10] 定义了 10 个元素，却访问 a[15]，memcheck 很可能一声不吭——它只在越界碰到了“不可访问页”或触发了 malloc 元数据破坏时才报警，属于被动检测。
真正能主动捕获这类问题的是 AddressSanitizer（ASan），不是 Valgrind。但如果你必须用 Valgrind 生态，有两条路：
- 用 Valgrind 的实验性工具
exp-sgcheck（已废弃，不推荐，仅旧版支持） - 改用
memcheck+ 编译时插桩：给代码加-fno-omit-frame-pointer -g，并配合--tool=memcheck --track-origins=yes，虽不能直接标出越界下标，但能帮你定位到越界引发的后续错误（如越界写破坏了邻近变量，导致后续读取该变量时报Invalid read of size X）
用 AddressSanitizer 替代 Valgrind 查越界更直接
绝大多数 C/C++ 项目查数组越界，AddressSanitizer 是事实标准。它由编译器（GCC/Clang）集成，在编译期插桩，运行时实时拦截非法内存访问，并精准指出越界位置和上下文。
实操步骤很简单：
- 编译时加
-fsanitize=address -g -O1（-O1避免优化干扰行号） - 运行程序，一旦发生越界，会立即中断并打印类似这样的信息：
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000001c at pc 0x55e7b9a5c3d1 bp 0x7ffcc8a4b9e0 sp 0x7ffcc8a4b9d8 READ of size 4 at 0x60200000001c thread T0 #0 0x55e7b9a5c3d0 in main /tmp/test.c:5:10 - 错误里明确写了
heap-buffer-overflow或stack-buffer-overflow，还带文件名、行号、偏移量
注意：ASan 会增大内存开销（~2 倍）和运行时开销（2–3 倍），但调试阶段完全可接受；发布前关掉即可（去掉编译选项）。
Valgrind memcheck 能间接帮上忙的几种情况
虽然不直接报数组越界，但当越界行为引发二级效应时，memcheck 就能起作用。典型场景包括：
-
malloc后越界写，破坏了 glibc malloc 的 chunk 头部或 footer → 运行时调用free时报Invalid write of size X或Corrupted size vs. prev_size - 结构体成员越界写，覆盖了相邻字段 → 后续读该字段时报
Use of uninitialised value（如果被覆写为随机值）或Invalid read（如果覆写成野指针） - 局部数组越界写，破坏了函数返回地址或栈上其他变量 → 程序崩溃后用
--stacktrace-limit=20 --read-var-info=yes可辅助回溯
这时建议启动参数加上：valgrind --tool=memcheck --track-origins=yes --read-var-info=yes --num-callers=20 ./a.out
为什么别硬扛着用 Valgrind 查纯越界
根本原因在于设计目标不同：memcheck 是基于“内存块有效性”的检查器，它把堆内存划分为已分配/未分配/已释放三类区域，但对“某块已分配内存内部是否越界”，它不做细粒度边界校验；而 ASan 是基于“影子内存（shadow memory）”的字节级监控，每个内存字节都有对应状态位，天然支持越界判定。
强行用 Valgrind 查，往往要靠“越界后引发的连锁故障”倒推，耗时且易漏。尤其对未触发崩溃的静默越界（比如只读越界、或越界写入未使用的 padding 区域），memcheck 几乎无能为力。
真要用 Valgrind，就专注它擅长的事：泄漏、use-after-free、未初始化内存使用。越界这事，交给 gcc -fsanitize=address 或 clang -fsanitize=address 更省心。
