こんにちは！開発現場で日々、バグとの格闘に明け暮れているあなたへ。
ふとした拍子に「あれ？この変数の値、一体どこで書き換わったんだ……？」と、何時間もコードの海をさまよった経験はありませんか？特にマルチスレッド環境や複雑なポインタ操作が絡むC/C++の世界では、犯人（バグ）を見つけ出すのが本当に一苦労ですよね。
今回は、そんな果てしない変数追跡の旅を「秒速」で終わらせてしまう、GDB（GNU Debugger）の隠し持った最強の武器「データ・ウォッチポイント」の世界へご案内します。
これをマスターすれば、あなたのデバッグライフは劇的に楽になりますよ。さあ、一緒に扉を開けていきましょう！
—
1. なぜ「ウォッチポイント」が必要なのか？（ツールの本質）
私たちが普段よく使うデバッグ手法といえば、コードの特定の行に「ブレークポイント（Breakpoint）」を仕掛ける方法ですね。「この関数が呼ばれたら止める」というアプローチです。
しかし、こんな状況を想像してください。
- 「グローバル変数 `status_flag` が、なぜかプログラムのどこかで `0` から `1` に書き換わってしまい、異常終了する」
- 「どこから書き換わっているのか、呼び出し元が多すぎてブレークポイントを何個置けばいいか分からない」
ブレークポイントは「場所（行）」を基準に止めますが、ウォッチポイントは「メモリの状態の変化（値の書き換え）」を基準にプログラムを止めます。つまり、「犯人の名前（アドレス）は分かっているが、犯行現場（コード上の行）が分からない」という絶望的な状況でこそ、真価を発揮するのです。
ハードウェア・ウォッチポイントの仕組み
GDBのウォッチポイントは、CPUのデバッグレジスタ（x86系であればDR0〜DR3など）というハードウェアの機能を利用して実現されています。
つまり、ソフトウェア側で「変数の値を毎回監視するコードを挿入する」ような愚かな真似はせず、CPUの機能によって「指定されたメモリアドレスに書き込みがあった瞬間、CPUが自ら割り込みを発生させてプログラムを強制停止させる」仕組みになっています。だからこそ、動作速度をほとんど落とさずに監視ができるのです。
—
2. 最小にして最強の動作確認：HelloWorld的セットアップ
百聞は一見にしかず。実際に手を動かして、その圧倒的な威力を体感してみましょう。
ターゲットとなるCプログラムの作成
まずは、意図せぬメモリ書き換え（バグ）を模したCプログラムを用意します。
以下のコードを `watch_sample.c` として保存してください。
include
include
// 監視対象となる共有変数
int target_variable = 0;
// バックグラウンドで勝手に変数を書き換えるスレッド関数
void rogue_thread(void arg) {
sleep(1); // 1秒待機
// 犯行現場：ここで変数が書き換わる！
target_variable = 999;
return NULL;
}
int main() {
pthread_t thread;
printf(“メイン処理開始: target_variable = %d\n”, target_variable);
// 悪さをするバックグラウンドスレッドを起動
pthread_create(&thread, NULL, rogue_thread, NULL);
// メインスレッドは変数が変わるのを待ち続ける（ビジネスカウンタのつもり）
while (target_variable == 0) {
usleep(100000); // 0.1秒スリープ
}
printf(“異常検知！ target_variable が %d に変わりました。\n”, target_variable);
pthread_join(thread, NULL);
return 0;
}
デバッグ情報の有効化コンパイル
GDBで変数名やソースコードの行番号を正しく扱えるようにするためには、コンパイル時に `-g` オプションを必ず付与します。
デバッグ情報付きでコンパイル（スレッドライブラリのリンクも忘れずに）
gcc -g -pthread watch_sample.c -o watch_sample
—
3. 実践！GDBで「秒速」犯人特定コマンド操作
それでは、GDBを起動してウォッチポイントの威力を目の当たりにしましょう。
1. GDBの起動とブレークポイントの設定
まずはプログラムをGDB上で読み込み、`main` 関数で一度止めます。
gdb ./watch_sample
GDBが起動したら、`main` にブレークポイントを張って実行（`run`）します。
(gdb) break main
Breakpoint 1 at 0x73d: file watch_sample.c, line 20.
(gdb) run
Starting program: /path/to/watch_sample
Main processing started: target_variable = 0
Breakpoint 1, main () at watch_sample.c:20
20 printf(“メイン処理開始: target_variable = %d\n”, target_variable);
2. ウォッチポイントの設置（ここが本番！）
プログラムが `main` で止まっている状態で、監視したい変数 `target_variable` に対してウォッチポイントを設定します。
(gdb) watch target_variable
Hardware watchpoint 2: target_variable
`Hardware watchpoint` と表示されましたね。これでCPUのハードウェア機能を使った監視体制が敷かれました。
3. プログラムの継続と一瞬での捕捉
それでは、プログラムを再開（`continue`）させてみましょう。
(gdb) continue
Continuing.
Main processing started: target_variable = 0
[Thread 0x7ffff7c3b700 (LWP 12345) seterusnya…]
Hardware watchpoint 2: target_variable
Old value = 0
New value = 999
0x00007ffff7fa414a in rogue_thread (arg=0x0) at watch_sample.c:13
13 target_variable = 999;
……どうですか、この瞬間！
ユーザーが `continue` を押した直後、バックグラウンドスレッドが `target_variable` を書き換えた瞬間に、GDBが自動的にプログラムを強制停止させました。
さらに、以下の情報を一撃で教えてくれています。
- Old value = 0 （書き換え前の値）
- New value = 999 （書き換え後の値）
- 犯行現場のファイル名と行番号: `watch_sample.c` の 13行目 (`target_variable = 999;`)
- 犯人の関数: `rogue_thread`
スタックトレース（`backtrace` コマンド）を確認すれば、このスレッドがどこから呼ばれたのかも完全に特定できます。
—
4. 現場で役立つ！知っておくべきプロの技と注意点
ウォッチポイントは強力ですが、現場で使いこなすためにはいくつかの「お作法」があります。
① スコープと寿命に注意する
ローカル変数をウォッチする場合、その変数が生存しているスコープ（関数内など）にいる間しかウォッチポイントは有効に機能しません。関数を抜けて変数が破棄されると、GDBは自動的にそのウォッチポイントを削除（または無効化）します。
基本は「グローバル変数」や「ヒープ上に確保された永続的なメモリ」に対して使うものだと思っておくと安全です。
② 条件付きウォッチポイント（Conditional Watchpoint）
「値が特定の数値に変わった時だけ止めたい」という場合は、条件を付与できます。
(gdb) watch target_variable if target_variable == 999
これにより、ノイズとなる不要な書き込みを無視して、本当に知りたい瞬間だけをピンポイントで捕捉できます。
③ 読み込みも監視したい場合（rwatch / awatch）
今回は「書き込み」を監視する `watch` を使いましたが、特定の変数が「どこから読み込まれているか」を監視する `rwatch`（Read Watchpoint）、または「読み書きのどちらでも」監視する `awatch`（Access Watchpoint）も存在します。
※ただし、CPUのハードウェア仕様によっては対応していないアーキテクチャもあるため注意してください。
—
まとめ
今回は、GDBのハードウェア・ウォッチポイントを用いたメモリ書き換えの追跡手法について解説しました。
- ブレークポイントは「場所」、ウォッチポイントは「変化」を捉えるもの
- `watch 変数名` を実行するだけで、CPUの機能を使って不正な書き込みを瞬時にキャッチできる
- どの関数の何行目で変数が書き換わったのかが、一撃で判明する
大規模なソースコードや、複数人で作ったマルチスレッドアプリケーションにおいて、変数の意図せぬ書き換えは開発者を最も悩ませるバグの一つです。しかし、このウォッチポイントの存在を知っていれば、もう怯える必要はありません。
「あ、この変数、どこで書き換わってるんだ……？」と思ったその瞬間、ぜひ思い出してください。GDBのウォッチポイントが、あなたの最高の相棒になってくれますよ。
それでは、快適なデバッグライフを！