C言語での開発において、多くのエンジニアが最も頻繁に遭遇し、かつ頭を悩ませるエラーの一つが「Segmentation fault (core dumped)」です。
このエラーは、プログラムが実行中にオペレーティングシステムによって許可されていないメモリ領域にアクセスしようとした際に発生します。
一見するとプログラムが突然終了するだけの不親切なエラーに見えますが、その背後にはメモリ管理における明確なルール違反が隠されています。
本記事では、このエラーが発生するメカニズムから具体的な原因、そして現代的なツールを用いたデバッグ手順までを詳しく解説します。
エラーの正体を正しく理解し、効率的なデバッグ手法を身につけることで、開発スピードとプログラムの品質を大幅に向上させることができるでしょう。
Segmentation faultのメカニズム
Segmentation fault（セグメンテーション違反）は、現代のオペレーティングシステムが備えるメモリ保護機能によって引き起こされます。
プログラムが起動すると、OSは各プロセスに対して「仮想メモリ空間」を割り当て、セグメントと呼ばれる単位で管理します。
各セグメントには、読み取り専用、読み書き可能、実行可能といったアクセス権限が厳密に設定されています。
プログラムがこれらの権限を無視して、割り当てられていないメモリ番地や読み取り専用領域への書き込みを試みた瞬間、CPUが例外を検知します。
OSはこの例外を受け取り、プロセスの実行を強制的に停止させ、ユーザーに異常を知らせるためにシグナル（SIGSEGV）を送ります。
「core dumped」というメッセージは、終了時のプロセスのメモリ状態を「コアファイル」としてディスクに保存したことを意味しています。
このコアファイルを解析することで、エラーが発生した瞬間の変数の値や関数の呼び出し履歴を後から調査することが可能になります。
主な発生原因とコード例
Segmentation faultが発生する原因は多岐にわたりますが、その多くはポインタの不適切な操作に起因します。
ここでは、代表的な4つの原因について具体的なコード例と共に解説します。
NULLポインタや未初期化ポインタの参照
最も一般的な原因は、有効なアドレスを指していないポインタを介してメモリにアクセスすることです。
特に、NULLが代入されているポインタをデリファレンス（間接参照）しようとすると、ほぼ確実にこのエラーが発生します。
#include <stdio.h>
int main() {
int *ptr = NULL; // NULLで初期化
// NULLポインタが指す先に値を書き込もうとする
*ptr = 100;
printf("%d\n", *ptr);
return 0;
}Segmentation fault (core dumped)また、ポインタ変数を宣言した直後に初期化を忘れると、ポインタには不定な値（ゴミデータ）が入ります。
その不定なアドレスに対して読み書きを行うことも、セグメンテーション違反の直接的な引き金となります。
配列の範囲外アクセス（バッファオーバーフロー）
配列に対して、定義されたサイズを超えたインデックスでアクセスすることも危険な行為です。
配列の範囲を超えたアクセスは、隣接する他のデータ領域や、関数からの戻り先アドレスが格納された領域を破壊する可能性があります。
#include <stdio.h>
int main() {
int arr[5] = {1, 2, 3, 4, 5};
// インデックス5は範囲外（0から4までが有効）
// 運良く動くこともあるが、管理外のメモリに触れるとエラーになる
arr[10000] = 99;
return 0;
}小さな範囲外アクセスではエラーにならずに動作し続けることがありますが、これは「静かなるバグ」となり、後段の処理で予期せぬ動作を引き起こします。
一方で、大きく離れたアドレスにアクセスしようとすると、即座にOSが不正検知を行いSegmentation faultとなります。
スタック領域の枯渇（スタックオーバーフロー）
再帰関数の終了条件が不適切であったり、ローカル変数として巨大な配列を確保したりすると、スタック領域が不足します。
スタックポインタが割り当てられたスタックセグメントの境界を越えてしまうと、セグメンテーション違反として処理が中断されます。
#include <stdio.h>
void infinite_recursion() {
int large_array[1024]; // 関数を呼ぶたびにスタックを消費
infinite_recursion(); // 無限再帰
}
int main() {
infinite_recursion();
return 0;
}再帰呼び出しを利用する場合は、必ず適切なベースケース（終了条件）が設定されているかを確認しなければなりません。
書き込み禁止領域へのアクセス
文字列リテラルなど、プログラムの実行中に変更されることが想定されていない領域への書き込みも原因となります。
C言語において、ダブルクォーテーションで囲まれた文字列リテラルは、通常「読み取り専用データセグメント」に配置されます。
#include <stdio.h>
int main() {
// 文字列リテラルへのポインタ
char *str = "Hello";
// 読み取り専用領域の先頭を書き換えようとする
str[0] = 'h';
printf("%s\n", str);
return 0;
}このコードはコンパイルを通過しますが、実行時に書き込み権限のないメモリを操作しようとしたと見なされ、エラーが発生します。
デバッグツールを用いた原因特定の手順
Segmentation faultが発生した際、ソースコードを目視で確認するだけでは限界があります。
効率的に原因箇所を特定するためには、専用のデバッグツールを活用することが不可欠です。
GDBによるバックトレースの取得
GNUデバッガ（GDB）は、エラーが発生した際の実行行を特定するための最も標準的なツールです。
まず、コンパイル時に-gオプションを付けて、実行ファイルにデバッグ情報を埋め込みます。
gcc -g -o my_program my_program.c次に、GDBを起動してプログラムを実行します。
gdb ./my_program
(gdb) runプログラムが停止（Segmentation fault）したら、backtrace（またはbt）コマンドを入力します。
これにより、どの関数の何行目でエラーが発生したかがスタックトレースとして表示されます。
また、printコマンドを使って、その時点での変数の値を確認し、ポインタがNULLになっていないかを調査します。
Valgrindによるメモリ不正アクセスの検出
GDBが「エラーが起きた場所」を特定するのに対し、Valgrindは「エラーの原因となる不正な操作」を動的に検知します。
例えば、配列の範囲外アクセスや初期化されていないメモリの読み取りなどは、即座にエラーにならなくてもバグの原因となります。
valgrind --leak-check=full ./my_programValgrindを使用すると、メモリの確保（malloc）と解放（free）の不一致や、無効な領域へのアクセスを詳細なレポートとして出力してくれます。
AddressSanitizerによる高速なエラー検知
AddressSanitizer (ASan) は、コンパイラ（GCCやClang）に組み込まれた非常に強力なメモリチェックツールです。
コンパイル時に特定のフラグを指定するだけで利用でき、実行時にオーバーヘッドを抑えつつメモリ違反を検知します。
gcc -fsanitize=address -g -o my_program my_program.c
./my_programASanを使用すると、セグメンテーション違反が発生した際に非常に読みやすい形式でエラーの原因とスタックトレースが表示されます。
Valgrindよりも高速に動作するため、テストフェーズでの常時利用が推奨されています。
主な原因と対策の比較表
発生しやすい原因とその対策を、以下の表にまとめました。
| 主な原因 | 特徴 | 推奨される対策 |
|---|---|---|
| NULL参照 | 最も頻度が高い | ポインタ使用前にNULLチェックを徹底する |
| 範囲外アクセス | 配列操作時に発生 | ループ境界の確認とASanの活用 |
| 未初期化ポインタ | 不定なアドレスを指す | 宣言時に必ずNULLまたは有効な値で初期化する |
| 解放済みメモリ参照 | Dangling Pointer | freeした後はポインタにNULLを代入する |
| スタック枯渇 | 深い再帰や巨大変数 | 再帰条件の見直しやヒープ領域（malloc）の利用 |
再発防止のためのベストプラクティス
エラーが発生してから対処するだけでなく、最初からSegmentation faultを起こしにくいコードを書く習慣が重要です。
第一の習慣は、ポインタの初期化を徹底することです。
ポインタを宣言する際は、即座に有効なメモリを割り当てるか、少なくともNULLで初期化するようにしてください。
第二の習慣は、動的メモリ確保（malloc）を行う際に、必ず戻り値のチェックを行うことです。
OSのメモリが不足している場合、mallocはNULLを返しますが、これをチェックせずに使用するとSegmentation faultに直結します。
第三の習慣は、静的解析ツールの導入です。
コンパイラの警告レベルを最大（-Wall -Wextra）に設定し、些細な警告も無視せずに修正することで、潜在的なバグを未然に防ぐことができます。
また、昨今の開発環境では、前述したAddressSanitizerを開発の初期段階から有効にしておくことが、最も確実な防御策となります。
まとめ
C言語における「Segmentation fault (core dumped)」は、決して恐れるべきエラーではありません。
これは、コンピュータの健全な動作を守るために、OSが不正なプログラムを安全に停止させてくれた結果だからです。
エラーが発生した際は、まずGDBを用いて発生場所を特定し、AddressSanitizerやValgrindで不正な操作の履歴を追跡してください。
ポインタの初期化、NULLチェック、配列の境界確認といった基本を忠実に守ることで、この種のエラーの大部分を排除できます。
メモリ管理を自分自身で制御するというC言語の難しさは、同時に低レイヤへの理解を深める絶好の機会でもあります。
本記事で紹介した手順を参考に、メモリ保護違反のメカニズムを理解し、より堅牢なプログラムの作成に取り組んでみてください。