本文主要是介绍以keepalived为例说明程序不能正常被gdb调试的原因，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
现象
通过gdb att $keepalived_pid发起对当前运行keepalived的调试；
在放行keepalived继续执行后，想通过Ctrl+C按键中断执行，观察下被调试程序的当前内部状态，
但是，在终端输入Ctrl+C后，导致keepalived被调试进程退出。
gdb无法对keepalived进行正常的调试交互！
结论先行
gdb与inferior process之间通过ptrace系统调用，以及对signal信号的拦截、传递进行调试交互过程- 由终端触发的
signal会首先被Kernel路由到inferior process，然后再被gdb截获 Linux Kernel针对inferior process信号存在特别的路由机制，会导致某些应用使用了特别信号捕获机制，例如，sigwait or signalfd，并处理了SIGINT信号，则不能被gdb正常调试
缘由
以前就了解到，如果被调试程序使用到类似sigwait特殊的信号捕捉机制，将会导致gdb调试程序遇到麻烦，特别是无法正常使用Ctrl+C按键，中断暂停被调试程序，进行正常的交互操作。
最近遇到keepalived一些问题， 就想用调试的方法看看它的运行时逻辑，在这时就遭遇了现象一样的调试失败。
先搜索了下keepalived源码，并无sigwait的使用过程，因为以前看那篇介绍比较粗，不知道除了sigwait使用方式外，还有signalfd使用方式，也会导致GDB调试遭遇类似问题。
而且，当时觉得keepalived作为比较出名的开源软件，应该不会不支持被调试，所以，并没有在第一时间发现原因。
分析
采用了分掘挖进的方法：
- 用不同的
keepalived版本 - 用不同的
linux部署环境、不同的gdb版本
来分析、验证这个问题，结果发现表象却出奇的一致！
最后，懒得继续研究下去其中到底为什么了，就向keepalived社区提出了Keeppalived不能被正常调试的issue。
社区解决方案
keepalived社区称之为Linux Kernel signal bug，但Linux社区保持这样的信号处理特性，有其原因。
最终，
keepalived社区用新增启动参数项--ignore-sigint来解决这个问题。
图解
参考
- Keeppalived不能被正常调试的issue
- 社区新增–ignore-sigint option的commit
- E文 Linux信号路由特殊机制导致GDB正常Ctrl+C却调试失败
- E文 调试的信号传递过程
- E文 GNU GDB 信号处理相关命令
这篇关于以keepalived为例说明程序不能正常被gdb调试的原因的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
