POSTED BY
2023-02-26

nodeやpythonなどのスクリプト言語は一切関係ないが、C/C++でコンパイルして制作したバイナリプログラムは実行時にSegmentation Faultエラーで落ちた場合、どこでどう落ちてしまったのか知る必要がある。これの手がかりになるのが、エラー時にOSによって吐かれるcoreファイルである。

このcore、ファイルサイズが大きいので、多くのOSではデフォルトで出力されるようにはなっていない。吐かせるには設定をする必要があるが、よく以下の方法が紹介されている。

ログインファイル.bashrcまたは/etc/profileに
ulimit -S -c unlimited
と記述する

確かにこの方法は、コンソールログインしてプログラムを手動でテスト起動して落とす場合ならcoreが吐かれる。しかしプログラムがApacheなどデーモンプロセスに起動してもらう＝CGIプログラムである＝場合は全く意味をなさない（coreは吐かれない。)

/etc/sysctl.confのkernel_coreとか/etc/security/limits.confのsoft coreとかの設定をせよとかを見かけるが、Debianではこれらも意味は無い。

正解は非常に単純で、

/etc/systemd/system.conf

で、以下の行を有効にすればいいだけである。

DumpCore=yes
DefaultLimitCORE=infinity

そして、目当てのプロセスがcoreを吐いてくれる設定かの確認は、

/proc/(プロセス番号)/limits

で確認できる。psコマンドでプロセス番号を調べて、確認する。

ps aux | grep apache

root        601  0.0  0.7 109032  7548 ?        Ss   00:16   0:00 /usr/sbin/apache2 -k start
hogeuser     621  0.0  0.8 726268  8560 ?        Sl   00:16   0:00 /usr/sbin/apache2 -k start
hogeuser      622  0.0  0.7 594972  7240 ?        Sl   00:16   0:00 /usr/sbin/apache2 -k start
root       3815  0.0  0.1  13800  1004 pts/0    S+   00:43   0:00 grep apache

↑CGIが起動するであろう子プロセスが自分ユーザ権限で動いてることを確認

cat /proc/621/limits

Limit                     Soft Limit           Hard Limit           Units
Max core file size        unlimited            unlimited            bytes

と、coreがulimited=coreが作成される設定であると確認できる。

この設定になっていれば、Apache経由の自分CGIが落ちたら、CGIのカレントディレクトリにcoreファイルが吐かれるので、gdbでデバッグができる。

gdb test.cgi core
# gdb が起動したら、
thread apply all bt
と打つ。すると、だいたいどこの何て関数で落ちたかわかる。

デバッグのためには、gcc -g オプションで、デバッグシンボルを有効にしてコンパイルしておかなくてはならない。