コアファイルは,プロセスのメモリダンプである.当然ダンプするタイミングによって内容は変わる.で,コアを使用することで,ダンプした時点での,プロセスの各変数の内容やスタックなどの情報を入手できる.要するにコアはデバッグに有用な情報を提供してくれる.

gdbでは

generate-core-file

でコアを吐ける.以下のサンプルを使用して実際にやってみる. まず-gをつけてコンパイルし,gdbを起動.そして10行目にブレークポイントを設定して実行.

> gcc -g hoge.c 
> gdb a.out 
(gdb) break 10
(gdb) run
Breakpoint 1, main (argc=1, argv=0xbffff6b4) at hoge.c:11
11		  fprintf (stdout, "hoge %d\n", i);
(gdb) print i
$1 = 0

iは今0である.で,適当に何回かcontinueしてみる.今回はi=5でブレークした状態でコアを吐いてgdbを終了する.

(gdb) generate-core-file
Saved corefile core.1676

今回はcore.1676というコアファイルが出力された.

> ls core*
core.1676

で,このコアファイルを使用してgdbを起動.

> gdb a.out core.1676
...省略...
#0  main (argc=1, argv=0xbffff6b4) at hoge.c:11
11		  fprintf (stdout, "hoge %d\n", i);
(gdb) print i
$1 = 5

いろいろと出力されて,ダンプ時点のプロセスの状態が再現される.実際iの値は5である.

上の例はどうも引っかかる.コアファイルと-g付きでコンパイルされた実行ファイルがあれば,gdbでのデバッグ作業がかなり楽になる.再現性の低い障害の場合は特に.問題はコアファイルの生成である.gdbで起動してgenerate-core-fileを実行するというのは,後で再現したい場合や,止められないシステムなどにそれなりに有用ではあるが,あまり意味がないように思える(その場でデバッグすればよい).プログラムの状態に応じてgdbに依存しない形でプログラムが自発的にコアを吐いてくれる仕組みが必要なのである.man 7 signalによると,SIGQUIT,SIGILL,SIGABRTなどを受信したプロセスはコアを吐いて終了するとある.さらに

> ulimit -c

でコアファイルサイズの最大値が分かる.私のシステムでは0に設定されていて,(一般ユーザでは)2以上には設定できないようになっていた(※).このあたりの設定を変更してプログラムの適当な場所でabortなどするとコアが吐かれるだろうか(なんかうまくいかない).