编译时必须加 -g -o0：gcc -g -o0 -wall main.c -o main，因 -o0 防止优化导致变量丢失或行号错位，-wall 可提前发现越界隐患，gdb 仅能在崩溃后定位而非主动检测越界。
用 gdb 启动带调试信息的程序
数组越界本身不会在编译时报错，但常导致 Segmentation fault (core dumped) 或静默数据破坏。GDB 无法“主动检测”越界，只能在崩溃后定位现场——所以第一步必须让程序可调试。
确保编译时加 -g -O0：gcc -g -O0 -Wall main.c -o main。-O0 关键：开启优化（如 -O2）会让变量被寄存器优化掉、行号错位，甚至掩盖越界访问的触发点；-Wall 能提前发现类似 for (i = 0; i 这类边界隐患。
崩溃后用 backtrace 定位越界语句
运行 ./main 崩溃后，立刻用 gdb ./main core（或 gdb ./main 后 run 复现）进入调试状态。
执行 backtrace（简写 bt），看最顶层栈帧（#0）在哪一行触发了段错误。
常见现象：
• #0 0x00005555555551a2 in crash () at main.c:15 → 直接跳到 main.c 第 15 行
• 如果该行是数组赋值（如 arr[i] = x;），再用 print i 和 print sizeof(arr)/sizeof(arr[0]) 对比确认是否越界
• 若该行是函数调用（如 strcpy(dst, src);），说明越界发生在被调函数内部，需用 step 进入或检查传入的指针/长度参数
用 watch 监控数组内存变化
有些越界不立即崩溃（比如写到了相邻栈变量），需要观察“谁改了不该改的地址”。这时 watch 比断点更有效：
• 先 break main 启动，run 到入口
• 用 print &arr[0] 查数组首地址，比如输出 0x7fffffffeabc
• 执行 watch *(int*)0x7fffffffeabc（按实际类型和地址调整）
• continue，GDB 会在任何代码尝试修改这个地址时中断，并显示修改它的源码行
注意：watch 开销大，只对小范围关键数组用；且不能监控 malloc 分配的堆内存起始地址以外的位置（需配合 addresssanitizer）
为什么单靠 gdb 很难 100% 确认越界？
GDB 是事后调试器，它看到的是“结果”（崩溃/异常值），不是“越界行为本身”。比如：
• 写越界 3 字节可能覆盖下一个局部变量，但崩溃发生在 5 秒后读那个变量时
• 越界写入堆区可能破坏 malloc 的元数据，崩溃出现在下一次 malloc 或 free
• 优化开启后，arr[i] 可能被编译成直接地址计算，GDB 栈帧里看不到 i 的值
真正可靠的越界检测要靠编译期工具：gcc -fsanitize=address 或 valgrind --tool=memcheck，它们能在越界发生瞬间报错并给出精确行列号。GDB 更适合作为这些工具报错后的深度上下文分析手段。
