こんにちは！日々の開発、本当にお疲れ様です。
突然ですが、こんな経験はありませんか？
「何万回とループする処理の中で、たった1回だけ変数が意図しない `NULL` になる……。でも、どのタイミングで壊れているのか分からないから、とりあえず `printf` を大量に仕込んでログの海に溺れている」
……もし心当たりがあるなら、今日でその泥臭いデバッグとはお別れしましょう。
今回ご紹介するのは、低レイヤデバッガ GDB（GNU Debugger） の秘蔵の武器、「条件付きブレークポイント（Conditional Breakpoint）」 です。
これをマスターすれば、無限ループや数百万回の処理のなかから「本当にバグが起きた瞬間」だけをピンポイントで捕獲できるようになり、デバッグ時間が文字通り「半減」します。初心者の方にもすっと腑に落ちるよう、基本のキから優しく丁寧に紐解いていきますね。これをマスターすれば、毎日のコーディングが劇的に楽になりますよ。
—
1. GDBとは何か？なぜ低レイヤデバッガを知るべきなのか
GDBは、C言語やC++などで書かれたプログラムの内部に深く入り込み、CPUがどのように命令を実行し、メモリがどう書き換わっているかをレントゲンのように透視できるコマンドラインのデバッガです。
普段私たちが使っているIDE（VS CodeやCLionなど）の「GUIデバッグ」の裏側でも、実はこのGDBやLLDBといった低レイヤデバッガがエンジンとして動いています。
つまり、GDBのコマンドを直接操る力を身につけるということは、「あらゆるデバッグツールの本質的な仕組みを掌握する」 ということに他なりません。
今すぐ使える環境構築（Ubuntu / Debian系の場合）
もしお手元にLinux環境（またはWSL）があれば、以下のコマンド一発でインストールできます。
パッケージリストを最新化し、GDBとコンパイラ（gcc）をインストールする
sudo apt update && sudo apt install -y gdb build-essential
—
2. 精度高い「Hello World」ならぬ「バグ再現コード」での動作確認
百聞は一見にしかず。まずはわざとバグを含んだ小さなプログラムを作って、GDBの基本動作を確認してみましょう。
以下のコードを `counter.c` という名前で保存してください。
include
int main() {
int sum = 0;
// 0から9999までループを回す
for (int i = 0; i < 10000; i++) {
sum += i;
// 意図しないバグ：iが5000のときに特別な処理を行いたいが、
// ここで別の変数が壊れるというシナリオを想定
if (i == 5000) {
// デバッグ対象の怪しいポイント
int bug_trigger = i 2;
(void)bug_trigger; // 警告回避
}
}
printf("計算完了！ 合計値: %d\n", sum);
return 0;
}
デバッグ情報を込めてコンパイルする
GDBを使う上で最も重要なポイントがここです。コンパイル時に `-g` オプションを必ずつけてください。これにより、機械語と「ソースコードの何行目か」を紐付ける地図（デバッグシンボル）がバイナリに埋め込まれます。
-g オプションを付与して、GDBが読める形式でコンパイルする
gcc -g -o counter counter.c
—
3. 従来のデバッグの限界と、条件付きブレークポイントの魔法
普通に `break 10` などとループ内の行にブレークポイントを貼るとどうなるでしょう？
プログラムを実行(`run`)した瞬間、ループの1回目の `i = 0` で容赦なく処理が停止してしまいます。
「いや、見たいのは `i = 5000` の瞬間なんだよ！」
ここで1万回も `continue` キーを連打しますか？ 指が疲れて腱鞘炎になってしまいますよね。
ここで登場するのが、条件付きブレークポイントです。
実践：GDBを起動して条件を設定してみよう
先ほどコンパイルしたプログラムをGDBで読み込みます。
GDBを起動し、counterバイナリを読み込ませる
gdb ./counter
GDBが起動したら（プロンプトが `(gdb) ` になったら）、以下のコマンドを叩いてみてください。
(gdb) break counter.c:10 if i == 5000
【このコマンドの解説】
- `break counter.c:10` : `counter.c` の10行目にブレークポイントを仕掛けます。
- `if i == 5000` : 「ただし、変数 `i` が 5000 のときだけ停止せよ」という強力な条件フィルターです。
設定が成功すると、GDBは以下のように応答します。
> `Breakpoint 1 at 0x… file counter.c, line 10.`
いざ、実行！
それでは、プログラムを実行してみましょう。
(gdb) run
どうでしょう？ 1万回のループを一瞬で（人間には知覚できないほどのスピードで）駆け抜け、まさに `i == 5000` になったその瞬間ピンポイントで、プログラムがピタッと止まりました。
ここで変数の中身を確認してみましょう。
(gdb) print i
$1 = 5000
(gdb) print sum
$2 = 12497500
見事に、バグが潜んでいる（あるいは怪しい挙動をする）その瞬間のスナップショットをノータイムで取得できました。これぞ、デバッグ時間を半減させる所以です。
—
4. プロが現場で使う「応用テクニック」とスマートな条件式
条件付きブレークポイントは、単なる「値の一致」だけでなく、もっと高度な条件を指定できます。実務で即座に使えるテクニックをいくつかご紹介しますね。
① 関数の呼び出し回数（ヒットカウント）で止める
「最初の数回は正常に動くのに、100回目に呼び出されたときだけメモリリークする」という厄介な関数がある場合、ブレークポイントの番号（ここでは例として `1` とします）に対して条件を追加できます。
既存のブレークポイント1番に対して、「50回目以降にヒットしたとき」という条件を追加
(gdb) condition 1 $_gdb_setting… （※簡易的には以下のようにコマンドを組み合わせます）
または最初から回数を指定してブレークポイントを作る場合
(gdb) break myFunction if $__bp_count > 100
※GDBの機能として、特定のブレークポイントに「無視する回数（ignore命令）」を設定することも可能です：
(gdb) break myFunction
(gdb) ignore 1 99 # 1番のブレークポイントを最初の99回は無視し、100回目で止める
② ポインタが NULL になった瞬間を捉える
C/C++で最も恐ろしい「Segmentation fault（セグメンテーション違反）」。ポインタが不意に `NULL` を指してしまうバグです。これも条件付きなら一撃です。
ptr というポインタが NULL (0) に等しくなったときだけ止める
(gdb) break process_data if ptr == 0
③ 文字列の内容で条件分岐する
構造体のメンバ変数（例: `packet->type`）が特定の文字列や特定のステータスコードになったときだけ止めたい場合も、Cの構文をそのまま使えます。
状態を表すステータスが ERROR (定数, 例: 3) のときだけブレーク
(gdb) break handle_packet if packet->status == 3
—
5. 現在設定されている条件の確認と管理
「どんな条件を仕掛けたっけ？」と忘れてしまったときは、`info breakpoints` コマンドで一覧を確認できます。
(gdb) info breakpoints
実行例：
Num Type Disp Enb Address What
1 breakpoint keep y 0x… in main at counter.c:10
stop only if i == 5000
breakpoint already hit 5001 times
なんと、「今までに何回この条件を評価し、何回スルーしたか（`breakpoint already hit 5001 times`）」まで優しく教えてくれます。不要になったら `delete 1` で消去すればOKです。
—
おわりに：道具を使いこなすエンジニアへ
「ログを仕込んで、ビルドして、実行して、ログを見て……」というサイクルは、時として開発者のメンタルをすり減らします。
GDBの条件付きブレークポイントは、いわば「コードの海に潜む特定の魚を、一発で釣り上げる特製ルアー」です。この武器をあなたの引き出しにそっと入れておくだけで、難解なバグに直面したときの絶望感が、ワクワクする謎解きの時間に変わります。
最初は少し黒い画面（CUI）に怯えてしまうかもしれませんが、今日試したコマンドを一つずつ使っていけば、すぐにあなたの頼もしい相棒になりますよ。
明日のコーディングが、もっと快適で楽しいものになりますように。先輩エンジニアより、愛を込めて。