こんにちは！日々の開発、本当にお疲れ様です。
突然ですが、こんな経験はありませんか？
「ローカルの手元では動くのに、Dockerコンテナの中に入れた瞬間にセグメンテーション違反（セグフォ）で落ちる……。でも、コンテナの中ってデバッガー入れにくいし、プロセスIDを見つけてアタッチしようにも権限エラーで弾かれるし、しまいにはソースコードのパスがズレてブレークポイントすら当たらない！」
……夜中の2時に一人、冷や汗をかきながらモニターを見つめるあなたの姿が目に浮かびます。大丈夫、あなたが悪いわけではありません。Dockerという「隔離された安全な世界」は、時として開発者にとっての「迷宮」に変貌するからです。
今回は、世界最高峰の開発環境を支えるアーキテクトである私から、Docker環境におけるGDBとLLDBの接続トラブルを100%解決するネットワークと権限の構成術を授けましょう。
これをマスターすれば、コンテナの中身がまるで手のひらの上のようによく見え、毎日のデバッグが劇的に楽になりますよ。さあ、一緒に紐解いていきましょう！
—
1. なぜDockerと低レイヤデバッガーは相性が悪いのか？（本質の理解）
まず、GDBやLLDBが裏側で何をやっているのかを知る必要があります。
これら低レイヤデバッガーは、OSのカーネル機能（Linuxなら `ptrace` システムコールなど）を使い、対象のプロセスを一時停止させたり、メモリを覗き見たりします。
しかし、Dockerコンテナはセキュリティ上の理由（コンテナエスケープの防止）から、デフォルトでは「他のプロセスを監視・制御する権利」を剥奪されています。さらに、コンテナという独立したネットワーク名前空間（Network Namespace）やファイルシステムを持っているため、ホストOS側から見ると「どこにいるのか分からない迷子」になってしまうのです。
この「権限の壁」と「空間の壁」を正しく取り払うことが、すべての解決の第一歩です。
—
2. 解決の要：`cap-add` でデバッグ特権を解放する
Dockerコンテナ内で動作するプロセスをホスト（あるいはコンテナ内）からデバッグするためには、Linuxカーネルのケーパビリティ（権限）を追加してあげる必要があります。
具体的には、`docker run` または `docker-compose.yml` において、`SYS_PTRACE` という権限を付与します。
実践：`docker-compose.yml` による環境構築の模範解答
以下の設定を見てください。これが、デバッグを完全に行うための黄金の構成です。
version: ‘3.8’
services:
debug-app:
build: .
image: my-c-cpp-app:latest
# 【最重要】ホストからプロセスを監視(ptrace)するための特権を付与
cap_add:
- SYS_PTRACE
# セキュリティ制約を緩和し、デバッガーがシステムコールを自由に叩けるようにする
security_opt:
- seccomp:unconfined
# ホストとコンテナのネットワークを共有する場合（必要に応じて）
network_mode: “host”
volumes:
# ホストのソースコードをコンテナにマウント（後述のパス同期のため重要）
- .:/app
command: [“./my_program”]
ここがポイント：
- `SYS_PTRACE`: これがないと、GDB/LLDBが `PTRACE_ATTACH` に失敗し、「Operation not permitted（許可されていない操作です）」という絶望的なエラーメッセージを吐くことになります。
- `seccomp:unconfined`: Dockerのデフォルトのセキュリティプロファイルは、一部の安全ではないとみなされるシステムコールをブロックします。低レイヤのデバッグではこれが足枷になるため、一時的に解除します。
—
3. コンテナの迷子を救う！ソースコードパスの完全同期術
権限問題をクリアして無事にデバッガーをプロセスにアタッチ（接続）できたとしましょう。しかし、次にあなたを待ち受けているのは「ブレークポイントを置いたのに、ソースコードが見つからない／行が一致しない」という罠です。
Dockerコンテナ内のビルド成果物（バイナリ）に埋め込まれたデバッグ情報（DWARF形式など）は、コンテナ内での絶対パス（例: `/app/src/main.c`）を指しています。しかし、あなたが手元のホストマシンで開いているのは `/Users/hoge/projects/my-app/src/main.c` かもしれません。このパスのズレこそが、デバッガーが迷子になる原因です。
これを解決するのが、GDBの `set substitute-path` および LLDBの `settings set target.source-map` です。
GDBの場合の設定術
GDBを起動したら（あるいは `~/.gdbinit` に記述しておけば）、以下のようにパスの置換ルールを教え込みます。
コンテナ内のパス(/app)を、手元のホストのパス(/Users/hoge/projects/my-app)に読み替える
(gdb) set substitute-path /app /Users/hoge/projects/my-app
これで、バイナリが指すコンテナ内のパスと、あなたが手元で見ているソースコードのパスが完璧に橋渡しされます。
LLDBの場合の設定術
LLDB（macOSや最新のLLVMエコシステムで主流）の場合は、コマンドが少し異なります。
コンテナ内のパスとホストのパスをマッピング
(lldb) settings set target.source-map /app /Users/hoge/projects/my-app
この一行を実行した瞬間、霧が晴れるようにソースコードの該当行がデバッガー画面に表示され、ステップ実行が可能になります。感動的ですよ！
—
4. 精度高い HelloWorld 的な動作確認フロー
百聞は一見にしかず。実際にこの構成が正しく動くか、最小限のC言語プログラムで検証してみましょう。
ステップ1: テスト用ソースコードの準備 (`main.c`)
include
include
int main() {
int counter = 0;
while (1) {
printf(“Debugging… counter = %d\n”, counter);
counter++;
sleep(2); // 2秒ごとにカウントアップするだけのシンプルなプログラム
}
return 0;
}
ステップ2: デバッグ情報を有効にしたDockerfile
最適化（`-O0`）をかけ、デバッグ情報（`-g`）をしっかり埋め込むのが低レイヤデバッグの鉄則です。
FROM gcc:latest
WORKDIR /app
COPY main.c .
-g でデバッグ情報を付与し、-O0で最適化によるコードの消滅を防ぐ
RUN gcc -g -O0 main.c -o my_program
CMD [“./my_program”]
ステップ3: 起動とアタッチの実践
1. 先ほどの `docker-compose.yml` と Dockerfile を同じディレクトリに配置し、ビルド＆起動します。
docker-compose up -d
2. コンテナ内で動いているプロセスのPID（プロセスID）を調べます。
docker-compose exec debug-app ps aux
# またはホストから
docker inspect –format ‘{{.State.Pid}}’ <コンテナIDまたはサービス名>
3. ホストからコンテナ内のGDBへアタッチします（コンテナ内にGDBをインストールしている場合、あるいはデバッグ用コンテナに入る場合）。
# コンテナのネットワーク・PID名前空間を共有している場合、ホストから直接叩くことも可能
gdb -p
4. GDBが起動したら、パスを置換し、main関数にブレークポイントを仕掛けます。
(gdb) set substitute-path /app /path/to/your/host/project
(gdb) break main
(gdb) continue
見事に `main` 関数でプログラムがピタリと止まり、手元のソースコードが表示されましたね？おめでとうございます。あなたはもう、Docker環境における低レイヤデバッグの迷子ではありません。
—
先輩エンジニアからのエール
コンテナ技術と低レイヤのデバッグは、一見すると相性が悪いように思えますが、カーネルの権限（`SYS_PTRACE`）と、ファイルパスの概念（`source-map` / `substitute-path`）さえ正しく理解してしまえば、恐れるに足りません。
この構成を一度テンプレートとしてプロジェクトに組み込んでおけば、本番環境に近いコンテナ内部の挙動であっても、手元の開発環境と全く同じ鮮度で解析できるようになります。
「なぜ動かないのか」を勘で推測する時間はもう終わりです。デバッガーという最強のメスを手に、コードの深淵を鮮やかに切り込んでいってください。あなたの開発ライフが、今日からさらに快適でエキサイティングなものになることを心から応援しています！