valgrind memcheck无法可靠检测栈上越界读写，因其仅监控堆和静态区，不检查局部变量边界；栈越界需依赖addresssanitizer等编译器防护手段。
Valgrind Memcheck 对栈访问错误的检测能力有限
不能可靠检测栈上越界读写，这是 Memcheck 的明确限制，不是配置或版本问题。
Memcheck 只监控堆内存（malloc/new 分配）和静态数据区，对函数调用栈上的局部变量（如 int arr[5]）不做边界检查。即使你访问了 arr[10] 或 arr[-1]，只要没踩到栈保护页或触发系统级段错误，valgrind --tool=memcheck 就不会报错。
- 典型不报错场景：
char buf[8]; printf("%c", buf[12]);—— Valgrind 输出ERROR SUMMARY: 0 errors - 它可能间接暴露栈问题：比如栈溢出导致返回地址被覆写，后续跳转异常，但此时报错位置已偏移，难以回溯到原始越界点
- 若栈越界恰好写入了相邻的 heap 内存（如某些 ABI 下栈紧邻堆），才可能被检测到，但这属于巧合，不可依赖
想查栈越界，得换工具或编译选项
Linux 下更直接有效的方式是启用编译器内置防护，而不是指望 Valgrind。
- 用
gcc -fsanitize=address编译：Clang/GCC 的 AddressSanitizer 能精准捕获栈、堆、全局区的越界访问，包括arr[10]这类访问，并给出源码行号和内存布局快照 - 加
-fstack-protector-strong：插入栈保护金丝雀（canary），在函数返回前校验，可捕获部分栈溢出（如缓冲区覆盖返回地址），但不报告具体越界位置 -
valgrind --tool=exp-sgcheck（已废弃）曾尝试支持栈检查，但自 Valgrind 3.12.0 起被移除，当前稳定版不再提供
为什么 Memcheck 不做栈检查？设计取舍使然
不是技术做不到，而是权衡性能与精度后的主动放弃。
- 栈操作极频繁（函数调用、局部变量读写），逐条插桩会带来数十倍性能下降，远超 Memcheck 本身约 20–30 倍的开销
- 栈内存生命周期短、布局紧凑，错误常表现为“静默损坏”或延迟崩溃，定位难度高；相比之下，堆错误更容易建模和拦截
- 主流做法是分层防御：编译期用 ASan 查栈/堆，运行期用 Memcheck 查堆/泄漏，两者互补而非替代
实际调试中容易忽略的关键点
看到 Segmentation fault 就下意识跑 Valgrind，结果一无所获——这往往说明问题出在栈上，或者用了 alloca、变长数组（VLA）、内联汇编等 Memcheck 不覆盖的区域。
此时应立刻检查是否启用了 ASan；若必须用 Valgrind 流程，至少补上 --track-origins=yes 看未初始化值来源，有时栈变量未初始化被传入堆操作，会由 Memcheck 在堆路径上暴露出来。
