GDB单步执行卡在fgets或scanf上是程序阻塞于stdin输入，并非GDB异常；此时在GDB终端输入内容并回车即可继续，或改用echo "input" | gdb ./a.out等方式重定向输入。
gdb单步执行时卡在fgets或scanf等输入函数上
这不是GDB卡住，是程序真的在等标准输入（stdin）。GDB本身不接管终端输入流，它只是暂停了程序执行，而fgets、scanf、getchar这类函数会阻塞等待用户从键盘敲入内容。如果你没输，它就一直挂在那里。
常见现象：next或step后光标不动、无提示、无报错，bt显示栈顶停在read、__libc_read或具体输入函数内。
- 确认是否真在等输入：执行
info proc mappings看进程状态，或另开终端用ps -o pid,stat,comm -p $PID查该进程的STAT列——若为S（sleeping）且comm是你的程序名，大概率就是阻塞在系统调用上 - 直接输入内容回车即可继续：比如程序卡在
fgets(buf, 100, stdin)，你在当前GDB终端里敲一行字符再回车，next就会往下走 - 不想手动输？改用重定向：启动GDB前把输入准备好，例如
echo "hello" | gdb ./myapp，或在GDB里用run
用run重跑时仍卡在相同位置，但想跳过输入逻辑
你不需要每次重输，也不必改代码。关键是让输入函数“立刻返回”，绕过交互环节。
- 设置断点在输入函数返回前：比如
break fgets，运行后停住，再return命令强制返回（慎用，可能破坏后续逻辑） - 更稳妥的是跳过整段输入：用
until跳到输入语句之后的某一行，例如until 42（假设第42行是fgets下一行） - 或者临时修改变量：如果输入结果存进
buf，可在fgets调用前用set variable buf[0] = 'h'等预设值，再next让它“读到”假数据 - 注意：
step进scanf内部会陷入libc源码（除非你装了debuginfo包），此时应改用next跳过
多线程下主线程卡输入，但其他线程还在跑
这时候next看似无效，其实是GDB默认只控制当前线程（通常是主线程），而别的线程仍在后台执行——比如一个子线程在刷日志、发网络请求，你会看到输出乱入调试界面。
- 先执行
info threads确认是否多线程活跃；若有多个LWP且状态不是idle，说明其他线程没停 - 用
set scheduler-locking on锁住调度器，让GDB单步时只运行当前线程，其余全部暂停 - 检查是否误用了
step进了某个线程创建函数（如pthread_create），它内部会切线程上下文，导致next行为异常；此时应回退用finish跳出该函数 - 若需观察后台线程行为，切换过去：
thread 2再bt，但别在非当前线程上next——GDB不允许
gdb --args启动后run卡住，但程序本不该等输入
这往往意味着程序依赖的某个环境没到位，比如标准输入被意外关闭、重定向出错，或程序本身检测到非交互式终端后改变了行为（如某些CLI工具自动禁用prompt）。
- 检查
stdin是否有效：在GDB中执行call isatty(0)，返回0说明当前stdin不是终端（tty），很多输入函数会因此立即失败或返回EOF - 强制恢复终端行为：
call dup2(0, 0)通常无效；更可靠的是启动时确保连接真实终端，例如gnome-terminal -- gdb ./myapp - 查看文件描述符：
info proc fds（需GDB 8.0+），确认fd 0是否指向/dev/pts/N而不是/dev/null或管道 - 如果程序用
getline或C++的std::cin，它们对非tty输入更敏感，可临时替换成fgets(stdin)测试是否为库层差异
最常被忽略的一点：GDB里的“输入”和你平时终端敲命令是同一套stdin，没有隔离。你以为在给GDB打字，其实全进了被调程序——所以别在卡住时狂按Ctrl+C，那会发信号给程序而非GDB；要用Ctrl+Z挂起GDB自身，再用fg切回来。
