KDevelop调试警告：无法设置控制终端：不允许操作

发布于 2024-12-04 13:02:25 字数 233 浏览 0 评论 0 原文

前段时间我把个人操作系统换成了linux，开发环境换成了KDevelop。

然而，调试 C++ 项目仍然无法正常工作。我的 KDevelop 版本是 4.2.2（我通过包管理安装了它）

每次我点击“调试按钮”时，应用程序都会以控制台消息启动 警告：GDB：无法设置控制终端：不允许操作并且调试功能不可用。

欢迎任何想法。

（如果您需要更多信息，请随时询问）

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

绻影浮沉 2024-12-11 13:02:25

我也遇到了这个问题，但我在 KDevelop 中很少使用 gdb，这还没有困扰我。这是我尝试修复它的日志：

Grepping 通过 GDB 7.3.1 源代码显示，当 GDB 尝试将其主 TTY 设置为新创建的伪 tty 时，会打印此消息（请参阅 gdb/inflow.c，第 683 行） -740）。特别是，使用请求 TIOCSCTTY 调用 ioctl 失败并出现权限错误。

考虑到这一点，我查看了 Linux 内核源代码，看看是什么导致了失败。一些搜索表明它最终会退化为对 tiocsctty() 的调用。 tiocsctty 的评论在这里很重要：

/*
 * The process must be a session leader and
 * not have a controlling tty already.
 */

由于 EPERM 失败的唯一原因是 GDB 创建的 tty 实际上是另一个进程的控制 tty（这似乎不太可能），我认为可以合理地假设 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 组的一部分，所有相关文件都是可读可写的。

通过 Grep 浏览 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 以使其正常工作（或者首先找到实际上导致其停止工作的原因......），所以我目前能建议的最好的办法就是不要使用用于调试目的的外部终端。

祝你好运！如果我发现任何有用的东西，我会更新。

I also had this problem, but I use gdb in KDevelop sparsely enough that hadn't bothered me yet. Here's my log of trying to fix it:

Grepping through the GDB 7.3.1 source code reveals that this message is printed when GDB tries to set its master TTY to a newly-created pseudo-tty (see gdb/inflow.c, lines 683-740). In particular, a call to ioctl with request TIOCSCTTY fails with a permissions error.

With this in mind, I took a look at the Linux kernel source code to see what could cause a failure. A bit of searching shows that it will eventually degenerate into a call to tiocsctty(). The comment from tiocsctty that is important here:

/*
 * The process must be a session leader and
 * not have a controlling tty already.
 */

Since the only other reason it can fail with EPERM is if the tty that GDB creates is actually a controlling tty for another process (which seems highly unlikely), I thought it reasonable to assume that GDB is not a session leader. Fair enough, it's launched by KDevelop after all!

So: I tried not launching the GDB session in an external terminal, and it works. Problem narrowed down.

Originally, the external terminal line was set to konsole --noclose --workdir %workdir -e %exe. Changing this to terminator -e %exe made a slight difference: KDevelop warned me that

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".

I checked my permissions; my user was part of the tty group and all relevant files were readable and writable.

Grepping through the KDevelop source code reveals how KDevelop actually sets up the terminal. It runs the shell script

tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done

and then sets up GDB to use the terminal device it reads from FIFO_PATH. (My name, by the way, not the one that KDevelop uses.) The problem (as best I can tell) is that gdb is not launched as a child of the shell script, and thus cannot use it as its main tty.

I'm not feeling up to patching KDevelop to make this work properly as of yet (or finding what actually caused this to stop working in the first place . . .), so the best I can suggest at the moment is to simply not use an external terminal for debugging purposes.

Good luck! I'll update if I find anything useful.

回复收藏 0 原文