断点未生效主因是程序未执行到该行，如函数未调用、分支跳过、提前退出或编译优化导致代码消失；其次为条件断点表达式错误、变量越界、多线程未适配、断点被禁用或未加载调试信息。
断点打上了但程序没停，大概率不是GDB坏了，而是断点根本没被触发——它压根没走到那行代码，或者被跳过了。
断点位置没被实际执行到
最常见的情况是：你用 break main 或 break 25 打了断点，但程序运行路径根本没经过那里。比如函数没被调用、分支条件为假、提前 return / exit / longjmp、或者代码被编译器优化掉了（尤其是未加 -g -O0 编译时）。
- 确认是否启用了调试信息：
file your_program输出里要有with debug_info；没有就重编译加-g - 检查是否开了优化：
readelf -S your_program | grep debug能看到调试节，但若gcc -O2下某些行可能被内联或删掉，list 25显示为空就说明这行已不存在于生成代码中 - 用
info breakpoints看断点状态，如果显示pending，说明 GDB 没找到对应符号或地址，得手动指定函数名或地址再试
断点被忽略或条件不满足
如果你用了 break if 或后续加了 condition，GDB 只在条件为真时暂停。哪怕断点命中了，条件不成立也会直接跳过。
- 执行
info breakpoints，看What列是否带stop only if，以及当前条件表达式写的是什么 - 注意变量作用域：条件里写的变量在断点位置可能还没定义、已被释放，或不在当前栈帧——GDB 会静默失败，不报错也不停
- 整数比较写成
i = 5（赋值）而非i == 5（判断），结果永远为真（非零即真），但逻辑完全反了
多线程下断点只对单个线程生效
GDB 默认只在当前线程设置断点。如果你的代码在子线程里执行，而断点打在主线程的函数上，那子线程跑过去根本不会触发。
- 用
info threads确认当前活跃线程，再用thread N切换后重新break - 想让所有线程都响应同一断点，得用
set breakpoint pending on+break，或启用全局断点模式：set follow-fork-mode child和set detach-on-fork off配合使用 - 注意：
break pthread_create这类系统调用断点，可能因 libc 内部实现绕过而失效，不如在目标线程函数入口打
程序本身绕过了断点机制
有些情况 GDB 的断点指令（int3）会被主动规避：比如程序自己读内存发现 0xcc 字节然后跳过、用 mprotect 改写代码段权限、或运行在不允许插桩的环境（如某些容器、seccomp 模式、KVM 虚拟化深度隔离场景）。
- 用
disassemble看断点位置反汇编，确认0xcc是否真实写入；没有的话说明断点没成功插入 - 尝试硬件断点：
hbreak（依赖 CPU 调试寄存器），对指令地址有效，但数量有限（通常 4 个） - 若程序 fork 后 exec 新进程，原断点不会自动继承，需用
set follow-fork-mode child并在子进程加载后重新打
真正容易被忽略的是：断点是否“活”着。很多人打了就以为万事大吉，但 disable 过没 enable、或 delete 后误以为还在、甚至 GDB session 断开重连后断点全丢——这些都不会报错，只是安静地不工作。
