こんにちは！日々のコーディング、お疲れ様です。
CやC++などの低レイヤに近い言語を触っていると、避けて通れないのが「セグメンテーション違反（Segmentation Fault、通称：セグフォ）」という赤い悪夢ですよね。
「突然プログラムが強制終了したけれど、原因のポインタがどこを指しているのか分からない……」
「printfデバッグを仕掛けようにも、クラッシュする場所が特定できない……」
そんな絶望感を味わったことはありませんか？
でも、安心してください。今日ここで、Linux開発における最強の相棒であるGDB（GNU Debugger）を用いたメモリ破損の究明術をマスターすれば、もうセグフォに怯える必要はなくなります。
今回は、初心者の方でも直感的に理解できるように、GDBの役割からコアダンプ解析、そしてメモリを監視する「ウォッチポイント」の極意まで、優しく丁寧にお伝えしていきます。これをマスターすれば、あなたのデバッグスピードは劇的に向上しますよ。
—
1. GDBとは何か？ なぜ低レイヤデバッガが必要なのか
私たちが普段書いているC/C++のコードは、コンパイラによって機械語（バイナリ）に翻訳されます。しかし、プログラムが実行時にメモリの不正な領域（存在しないアドレスや、書き込みが許可されていない領域）にアクセスすると、OS（カーネル）が即座にそのプロセスを強制終了させます。これがセグメンテーション違反です。
ここで登場するのが GDB（GNU Debugger） です。
GDBは、実行中のプロセスや、クラッシュした瞬間のメモリの残骸（コアダンプ）を直接覗き込み、「どの関数の、何行目で、どの変数が原因で破綻したのか」をピンポイントで暴き出すための超高精度なレントゲン装置です。
最低限知っておくべき「デバッグ情報」の仕組み
GDBを使う上で、絶対に外せない大前提があります。それは、コンパイル時に `-g` オプションを付与することです。
通常、コンパイラはバイナリを最適化する際、変数名やソースコードの行番号といった「人間用のメタデータ」を削ぎ落としてしまいます。`-g` オプションは、コンパイラに対して「バイナリの中に、ソースコードの対応表（シンボル情報）を残しておいてくれ」と指示する魔法の呪文なのです。
—
2. 基礎セットアップと「HelloWorld」ならぬ「セグフォ体験」
まずは、あえてバグを含んだプログラム（C言語）を用意し、GDBの基本操作を体感してみましょう。
準備：意図的にメモリを破壊するプログラムを作る
以下のコードを `segfault_sample.c` という名前で保存してください。
include
include
// 意図的に不正なメモリ書き込みを行う関数
void cause_segfault(void) {
// ヌルポインタ（アドレス 0x0）を定義
int ptr = NULL;
// 存在しないアドレスに値を書き込もうとする（ここでセグフォが発生する）
ptr = 42;
}
int main(void) {
printf(“プログラムを開始します…\n”);
// バグを内包する関数を呼び出す
cause_segfault();
printf(“この行には到達しません。\n”);
return 0;
}
コンパイルの作法
先ほど解説した `-g` オプションをつけてコンパイルします。
-g オプションをつけてデバッグ情報を付与し、最適化を無効化(-O0)する
gcc -g -O0 segfault_sample.c -o segfault_sample
※ `-O0`（オー・ゼロ）をつけるのは、コンパイラによる最適化でコードの行番号が前後するのを防ぎ、GDBで正確な位置を特定するためです。
実行してみましょう。
$ ./segfault_sample
プログラムを開始します…
Segmentation fault (コアダンプ)
見事にセグフォが発生しましたね。では、この犯人をGDBで追い詰めていきましょう。
—
3. bt（backtrace）コマンドで「犯行現場」を特定する
まずは、GDBを起動してプログラムを実行し、クラッシュさせてみます。
GDBに実行ファイルを読み込ませて起動
gdb ./segfault_sample
GDBのプロンプト（`(gdb)`）が表示されたら、以下のコマンドを入力します。
(gdb) run
（または短縮形の `r` と入力）
プログラムが実行され、次のようなメッセージが表示されてGDB内で一時停止します。
Starting program: /path/to/segfault_sample
プログラムを開始します…
Program received signal SIGSEGV, Segmentation fault.
0x0000555555555149 in cause_segfault () at segfault_sample.c:9
9 ptr = 42;
見てください！
GDBは「`segfault_sample.c` の9行目、`ptr = 42;` を実行した瞬間にSIGSEGV（セグメンテーション違反）が発生した」ことを一発で教えてくれました。
バックトレース（呼び出し履歴）を見る `bt` コマンド
実際の開発現場では、何重にも関数がネストしているため、「どこからその関数が呼ばれたのか」というコンテキスト（文脈）が重要になります。そこで使うのが `bt`（backtrace） コマンドです。
(gdb) bt
実行結果の例：
0 cause_segfault () at segfault_sample.c:9
1 0x0000555555555173 in main () at segfault_sample.c:16
- `#0` は、現在クラッシュが起きている最先端の場所（`cause_segfault` 関数）です。
- `#1` は、それを呼び出した親の場所（`main` 関数の16行目）です。
このように、`bt` を使えば「誰がこのバグを踏んだのか」というコールスタックの足取りを完璧に追跡できます。
—
4. コアダンプ解析：本番環境で起きた「幻のバグ」を暴く
開発環境ではなく、「リリースした本番サーバーやクライアント環境で突然アプリがクラッシュした！」という絶望的な状況を想像してください。その場には当然GDBはありません。
しかし、LinuxなどのOSには、プロセスが異常終了した瞬間のメモリの状態をファイルとして保存する「コアダンプ（Core Dump）」という素晴らしい機能があります。これがあれば、手元の開発マシンで「当時の状況を完全に再現」できます。
1. コアダンプの出力設定を有効化する
Linuxではデフォルトでコアダンプの出力が制限されている場合があるため、無制限に設定します。
ulimit -c unlimited
2. コアダンプ付きでプログラムを再実行する
先ほどのプログラムを再び実行すると、カレントディレクトリに `core` または `core.[PID]` というファイルが生成されます（※ディストリビューションの設定により保存場所が異なる場合があります）。
3. GDBにコアダンプを読み込ませる
実行ファイルと、生成されたコアダンプファイルを同時にGDBに渡します。
gdb ./segfault_sample core
GDBが起動した瞬間から、すでにプログラムは「クラッシュした瞬間」のメモリ状態を保持しています。ここで迷わず `bt` を叩いてみてください。本番環境でどこが壊れたのかが手に取るように分かります。これがプロの現場における標準的なクラッシュ調査フローです。
—
5. 特定のメモリアドレスを監視する「watchポイント」の極意
ここからが本題の真骨頂です。
「ポインタがNULLになるわけではないのに、なぜか意図しないタイミングで変数の値が書き換わってしまい、後続の処理でセグフォる」という、メモリ破壊の犯人探しにおいて最強の武器となるのが watchポイント です。
通常のブレークポイントは「行番号」や「関数名」で止めますが、watchポイントは「特定の変数やメモリアドレスの値が変化した瞬間」にプログラムを強制停止させます。
実践：メモリ破壊の犯人をwatchで現行犯逮捕する
次のような、変数が不正に書き換わるシナリオを考えてみましょう。
include
int target_variable = 100; // 守りたい大切な変数
void bad_function(void) {
int p = &target_variable;
// 離れた場所から、ポインタ経由で不正な値を書き込んでしまうバグ
(p + 10) = 999; // ここがメモリ破壊を引き起こす（仮の例）
}
int main(void) {
printf(“初期値: %d\n”, target_variable);
bad_function();
printf(“書き換わり後: %d\n”, target_variable);
return 0;
}
この「誰が `target_variable` を書き換えたのか分からない」状況をGDBで解決します。
1. GDBを起動し、main関数あたりで一旦止めます。
gdb ./memory_corruption_sample
(gdb) break main
(gdb) run
2. watchポイントを設定します。
(gdb) watch target_variable
解説: これにより、GDBは `target_variable` が格納されているメモリ領域を監視し始めます。値が書き換わると、自動的にプログラムが一時停止します。
3. 続行（continue）します。
(gdb) continue
4. 犯行の瞬間！
プログラムを実行すると、次のようにGDBが割り込みます。
Hardware watchpoint 1: target_variable
Old value = 100
New value = 999
0x0000555555555139 in bad_function () at memory_corruption_sample.c:8
8 (p + 10) = 999;
お見事です！ `target_variable` の値が変化した瞬間を捉え、どのコードがそれを書き換えたのか（`bad_function` の8行目）を現行犯逮捕できました。
ポインタの誤算やバッファオーバーランによって「なぜか変数の値が壊れる」という複雑な不具合も、watchポイントを使えば一瞬で原因にたどり着けます。
—
おわりに：毎日のコーディングを劇的に楽にするために
今回は、GDBを使ったセグメンテーション違反の究明術と、コアダンプ解析、watchポイントの活用法について解説しました。
最初は黒い画面にコマンドを入力するCUIのデバッガに難しさを感じるかもしれませんが、一度この強力な「透視能力」を手に入れてしまえば、闇雲にprint文を埋め込むデバッグには二度と戻れなくなります。
「バグが出たら、恐れずにGDBでメモリを覗く」
この習慣をつけるだけで、低レイヤのコードに対する恐怖心は消え去り、あなたのエンジニアとしてのスキルは確実に次のステージへと引き上げられます。ぜひ、手元の環境で今回のコードを動かし、その強力さを体感してみてくださいね。
それでは、快適なデバッグライフを！