如何中断GDB中运行缓慢的命令且不终止会话？

我完全懂这种抓狂的感觉——不小心触发info functions这类遍历海量符号的命令，看着GDB占满CPU内存，常规的Ctrl-C、Ctrl-\都不管用，只能要么硬等要么用SIGUSR1杀掉重开，太折腾了。

给你几个不用终止GDB就能中断慢命令的实用方法：

1. 发送SIGUSR2信号（最快捷的应急方案） #

GDB内置了对SIGUSR2的特殊处理：它会中断当前正在执行的慢命令，但不会终止GDB会话，完美解决你的问题。操作步骤：

• 打开新终端，找到卡住的GDB进程ID：

  ps aux | grep gdb
  

• 发送SIGUSR2信号：

  kill -USR2 <你的GDB进程PID>
  

切回原来的GDB窗口，你会发现它立刻回到(gdb)提示符，一切正常，不需要重启。

2. 提前配置GDB避免触发卡死场景 #

为了从根源减少这种情况，你可以在~/.gdbinit里添加一些配置：

• 设置符号列表的显示上限，当输出超过阈值时GDB会询问是否继续，不会直接卡死：

  set symbol-limit 500
  

  之后再执行info functions这类命令，当列出的函数超过500个时，GDB会弹出Continue? (y or n)的提示，按n就能立刻终止输出。
• 给容易触发慢操作的命令加限制，比如只显示匹配特定模式的函数，避免全量遍历：

  alias info funcs = info functions ^my_program_
  

  这样用info funcs只会列出以my_program_开头的函数，不会遍历所有符号。

为什么常规信号没用？ #

当GDB在执行符号遍历、大型内存dump这类操作时，可能处于内核态的系统调用中（比如读取符号表文件），此时SIGINT、SIGQUIT的信号处理被暂时屏蔽了，所以无法中断。而GDB专门预留了SIGUSR2作为内部中断信号，绕过了这种屏蔽，专门用来安全中断当前命令。

内容的提问来源于stack exchange，提问作者Nathaniel M. Beaver