私もこの問題を抱えていましたが、KDevelopでgdbをまばらに使用しているので、まだ気になりませんでした。これがそれを修正しようとした私のログです:
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グループの一部であり、関連するすべてのファイルは読み取りと書き込みが可能でした。
KDevelopのソースコードを確認すると、KDevelopが実際に端末を設定する方法がわかります。シェルスクリプトを実行します
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
次に、FIFO_PATHから読み取った端末デバイスを使用するようにGDBを設定します。(ちなみに、私の名前は、KDevelopが使用している名前ではありません。)問題は(私が知る限り)、gdbがシェルスクリプトの子として起動されないため、メインのttyとして使用できないことです。
現時点では、この機能を適切に機能させるためにKDevelopにパッチを適用することに満足していません(または、そもそもこれが機能しなくなった原因を見つけること)。したがって、現時点で提案できる最善の方法は、単に使用しないことです。デバッグ用の外部端末。
幸運を!何か役に立つものがあれば更新します。