GDB是定位野指针最直接有效的手段，需配合-g编译、合理断点及x/info registers等内存观察命令；否则段错误后仅见崩溃而无法溯源。
野指针问题无法靠静态检查发现，GDB 是最直接有效的定位手段——但必须配合 -g 编译、合理断点和内存观察命令，否则只会看到 Segmentation fault 后一脸茫然。
编译时必须加 -g 且禁用优化
没有调试符号，GDB 连变量名都看不到；而 -O2 之类优化可能内联函数、重排指令，导致栈帧错乱或变量被优化掉。
- 正确编译命令：
gcc -g -O0 -o test test.c - 错误示范：
gcc -O2 test.c（bt可能只显示#0 0x... in ?? ()） - 验证是否有效：运行
file test，输出应含with debug_info
崩溃后第一时间用 bt 和 info registers
段错误发生时，GDB 会停在出错指令处。此时 bt 显示调用栈是起点，但关键在寄存器值——因为野指针解引用通常表现为对非法地址的读/写，$rax、$rdi 等寄存器里往往就藏着那个野地址。
- 执行
bt查看哪一行触发崩溃（比如test.c:23） - 立刻执行
info registers，找值明显异常的寄存器（如rax 0xdeadbeef或rdi 0x0） - 若寄存器值是
0x0，大概率是空指针；若为极小（0x1）或极大（0xfffffffffffff000）随机值，基本可判定为野指针
用 x 命令验证指针指向的内存是否合法
p ptr 只显示地址，真正要确认它是否“野”，得看这个地址能不能读、属于哪个内存段。
- 尝试读取前 4 字节：
x/4xb $rdi（假设野指针在%rdi） - 如果报错
Cannot access memory at address 0x...，说明该地址不可访问，是典型野指针 - 结合
info proc mappings查看进程内存布局，判断地址是否落在[heap]、[stack]或已释放的[anon]区域外 - 注意：不要用
*ptr直接打印，可能再次触发段错误
提前设 watch 监控指针值变化（适合悬垂指针）
有些野指针是“变质”出来的——比如 free 后没置 NULL，后续误用。这种场景下，等崩溃再查太晚，应该在释放点就埋监控。
- 在
free(ptr)上方设断点，停住后执行：watch *ptr - 继续运行，一旦代码试图读写该地址，GDB 会立即中断，并告诉你谁在碰已释放内存
- 注意：
watch是硬件断点，数量有限；优先用于关键指针，避免对大数组设watch arr[0]@100 - 更稳妥的做法是在
free后立刻加ptr = NULL，从源头杜绝悬垂
野指针真正的难点不在定位，而在确认“为什么它没被初始化/为什么释放后没置空”。GDB 能告诉你 ptr 此刻是野的，但得回溯代码逻辑才能堵住漏洞——比如检查所有分支路径是否都覆盖了指针初始化，或者用 valgrind --tool=memcheck 配合复现，它比 GDB 更早发现 use after free 行为。
