GCC本身不直接调试内存越界，但通过-fsanitize=address（ASan）可实时捕获堆/栈越界，精准定位行号、变量及偏移量；需配合-g和-O1，虽慢2–3倍但检测强于valgrind，且编译警告（如-Warray-bounds）和安全函数替代亦能预防部分越界。
gcc 本身不直接调试内存越界，但通过搭配特定编译选项和运行时工具，能让你在第一次越界发生时就精准捕获——不是等程序崩了再猜，而是直接报出哪一行、哪个变量、偏移多少字节。
用 -fsanitize=address 一跑就定位堆/栈越界
这是目前最实用、开箱即用的方案，尤其适合 Linux/macOS 开发环境。它不是“事后分析”，而是在非法访问发生的瞬间中断并打印完整调用栈。
- 必须加
-g：否则报错里看不到源码行号 - 推荐用
-O1（别用-O0）：ASan 在-O0下可能漏检或行为异常 - 编译命令示例：
gcc -fsanitize=address -g -O1 test.c -o test - 运行后一旦越界，会输出类似：
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000024 at pc 0x55e...，紧接着就是分配位置、越界访问位置、函数调用链 - 注意：ASan 会显著拖慢运行速度（约2–3倍），且不能用于裸机或 MCU 实际部署，只用于模拟器或 host 端测试
为什么不用 valgrind？它和 ASan 有啥区别
valgrind 是老牌工具，不需要重新编译，但代价明显：
- 它靠模拟 CPU 指令执行，速度极慢（通常比原程序慢 20–30 倍）
- 对某些优化后的代码（尤其是内联、寄存器变量）检测能力弱于 ASan
- 不支持检测栈上未初始化读取（ASan 支持
-fsanitize=undefined补充） - 启动命令简单：
valgrind --tool=memcheck ./test，但遇到多线程或信号密集场景容易误报或卡死 - 更适合验证已知可疑模块，而非日常开发中快速迭代排查
编译期警告也能提前拦住部分越界
有些越界在编译阶段就能发现，关键在于打开对应警告：-
-Warray-bounds：检测静态数组下标越界（如int a[3]; a[5] = 1;） -
-Wstringop-overflow=：检查strcpy、memcpy等函数的长度参数是否超限 -
-D_FORTIFY_SOURCE=2：配合-O2，让部分标准库函数（如fread、snprintf）在运行时做额外校验 - 注意：
-Warray-bounds对指针算术（如p[i]wherepis malloc’d）无效——这类必须靠 ASan 或手动检查
别忽略字符串函数这个重灾区
大量越界其实来自strcpy、sprintf、strcat 这类无长度限制的函数：
- 错误写法：
strcpy(dst, src);—— 完全依赖src以\0结尾且dst足够大 - 正确替代：
strncpy(dst, src, sizeof(dst)-1); dst[sizeof(dst)-1] = '\0'; - 更安全选择：
snprintf(dst, sizeof(dst), "%s", src);—— 自动截断并补\0 - 如果你用的是 musl 或较新 glibc，
strcpy在_FORTIFY_SOURCE=2下会被替换成带检查的版本，但前提是编译时没关掉优化
ASan 报错信息里常出现 heap-use-after-free 或 stack-buffer-overflow 这类术语，它们不是泛泛的“内存错误”，而是明确指向具体内存区域和操作类型。真正麻烦的不是发现越界，而是越界后没立即崩溃——数据被悄悄改写，几轮调用后才暴露，那种情况必须依赖 ASan 的实时拦截能力。
