我也遇到了这个问题,但是我在KDevelop中很少使用gdb,所以还没有困扰过我。以下是我尝试解决它的记录:
通过搜索GDB 7.3.1源代码,发现当GDB尝试将其主TTY设置为新创建的伪TTY时(参见gdb/inflow.c,行683-740),会打印出此消息。特别地,使用请求TIOCSCTTY的ioctl调用失败并出现权限错误。
基于这一点,我查看了Linux内核源代码,看看什么原因可能导致失败。经过一番搜索,最终会退化为调用tiocsctty()。这里有一个来自tiocsctty的注释很重要:
由于GDB创建的tty实际上是另一个进程的控制tty(这似乎非常不可能),因此它失败并出现EPERM错误的唯一其他原因是,我认为合理的假设是GDB不是会话领导者。毕竟,它是由KDevelop启动的!
所以:我尝试在外部终端中不启动GDB会话,并且它可以正常工作。问题已经缩小了。
最初,外部终端行设置为konsole --noclose --workdir %workdir -e %exe
。将其更改为terminator -e %exe
略有不同:KDevelop警告我:
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
我检查了我的权限,我的用户是tty组的一部分,所有相关文件都可读可写。
在KDevelop源代码中搜索发现KDevelop实际上是如何设置终端的。它运行shell脚本。
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
然后设置GDB使用从FIFO_PATH读取的终端设备(顺便说一下,这是我的名字,而不是KDevelop使用的那个名字)。问题(据我所知)是gdb没有作为Shell脚本的子进程启动,因此无法将其用作主tty。
目前我感觉没精力去修补KDevelop使其正常工作(或找出导致它停止工作的原因),所以我能提供的最佳建议就是在调试时简单地不使用外部终端。
祝你好运!如果我发现任何有用的信息,我会进行更新。
gdb
从命令行工作是否符合预期? - Keith Layne