&"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"が出て困った話

事象

VScodeでC/C++拡張機能を使いF5でデバッグを押した
コンパイルは通ったのに、以下のような警告メッセージが出たまま動かなくなった

"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"

最終的な解決策

いくつか調べて回っているうちに、VSCodeのCodeLLDBを入れることを紹介していたスレッドやツイートを見つけた¹。

CodeLLDB拡張機能でLLDB経由でのデバッグを行えば一旦は回避可能だということがわかった。
根本的に解決したわけではなく暫定対策寄りにはなるものの今までのたまにデバッグがストップするフラストレーションからは脱出できそうなので、一旦これで対応することにした。

以下の拡張機能を使った。

環境

開発環境

• Docker環境 Ubuntu24.04
• VSCode
• GNU gdb (Ubuntu 15.1-1ubuntu1~24.04.1) 15.1

状況

以下はここに至るまでの紆余曲折をつらつらと記述する。

デバッグ環境の抜粋

軽くこの環境がどういうデバッグ環境だったかを記述する。

1. ユーザー(というか私)がF5を押すとLaunch.jsonのLaunch(Cpp)というラベルのデバッグ構成が呼び出される
2. デバッグ構成は、Tasks.jsonのcppBuildというビルドタスクを呼び出す
3. ビルドタスクが終了後、gdbによってデバッグを開始する

この事象は、2が終了後、3が開始したにも関わらず警告メッセージが出たまま動かなかった。

資料

Launch.json

    {
      "name": "Launch(Cpp/GDB)",
      "type": "cppdbg",
      "request": "launch",
      "program": "${fileDirname}/a",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "setupCommands": [
        {
          "description": "gdb の再フォーマットを有効にする",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        },
        {
          "description": "逆アセンブリ フレーバーを Intel に設定",
          "text": "-gdb-set disassembly-flavor intel",
          "ignoreFailures": true
        }
      ],
      "preLaunchTask": "cppBuild"
    }

Tasks.json

        {
            "type": "cppbuild",
            "label": "cppBuild",
            "command": "/usr/bin/g++",
            "args": [
                "-fdiagnostics-color=always",
                "-g",
                "${file}",
                "-I",
                "~/acl/",
                "-o",
                "${fileDirname}/a",
                "-std=c++23",
            ],
            "options": {
                "cwd": "${fileDirname}"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "reveal": "never",
                "panel": "shared"
            },
            "detail": "デバッガーによって生成されたタスク。"
        }

暫定対応

暫定1:GDB 12.1に落とす

GDBのバージョンがまだ上がっていない知り合いが問題なく動いていることを話していたので、合わせる形でGDBのバージョンを下げることにした。
ただし、これをするためにDockerのUbuntuバージョンを22.04に下げる必要があった(24.04イメージにはaptリポジトリにGDB12.2が入っていなかったため)。
ある程度上記の事象が発生しづらくなったため、実用に耐えられるとはいいがたいが、だましだまし使うくらいには収まった。
一緒に入れている他のパッケージへのダメージが大きくなかったため一旦これで暫定対応したが、かなり乱暴な対応となってしまったのでもう少し原因を探した。

暫定2:実行ショートカットを自作

何にもならない解決策ではあるが、デバッガを経由しなければこの事象は発生しない。
ということで、以下のようなシェルを用意して困ったらこのシェルをたたくことでがんばった。

execute.sh

compileProgram="/usr/bin/g++ -fdiagnostics-color=always -g <ファイル名> -I ~/acl/ -o ../dev/a -std=c++23 "
targetProgram="../dev/a " #Cpp

correctProgram="../dev/a" #Cpp

#!/usr/bin/env bash
pushd "$(dirname "$0")" > /dev/null
pushd .. > /dev/null
source config
# コンパイル（あれば実行）
if [ -n "${compileProgram:-}" ]; then
    echo $compileProgram
    eval "$compileProgram" || exit 1
fi
echo $targetProgram
eval $targetProgram
# 比較結果の出力
popd > /dev/null
popd > /dev/null

原因

VScodeのWSLサーバーまわりのバグっぽいということがわかった。
(全然原因が分かったとは言えないが、私としては解決できれば一旦困らないので、自分の手でどうしようもない部分の不具合であることがわかれば一旦原因をこれ以上探る必要はなかろうと思い手を引いた)
これ以外にもかなり多様な場所で、かつ執筆現時点でも活発に同じ問題が議論されているようなので、解決するときを待ちたいなぁと思った。

追記

20260526: どうやら件の拡張機能のバージョンを下げると解決するということが書いてあるのを見つけた。

これでもよかったな..

1. https://github.com/microsoft/vscode-cpptools/issues/121 ↩