/usr/src/linux/Documentation/sysctl/kernel.txt を読んでください。
<ブロック引用>core_pattern は、コア ダンプファイルのパターン名を指定するために使用されます。
- パターンの最初の文字が「|」の場合、カーネルは残りのパターンを実行するコマンドとして扱います。コア ダンプは、ファイルではなく、そのプログラムの標準入力に書き込まれます。
コア ダンプをディスクに書き込む代わりに、システムはコア ダンプを abrt に送信するように構成されています。 (意味:自動バグ報告ツール、ではない "abort") プログラムを代わりに使用してください。自動バグ報告ツールは、本来あるべきほど文書化されていない可能性があります...
いずれにせよ、簡単な答えは、/var/cache/abrt でコア ファイルを見つけることができるはずです。 、ここで abrt 呼び出された後に保存します。同様に、Apport を使用する他のシステムは、/var/crash でコアを追い払う可能性があります。 などです。
最近の Ubuntu (私の場合は 12.04) では、"Segmentation fault (core dumped)" が表示される可能性がありますが、予想される場所 (ローカルでコンパイルされたプログラムなど) にコア ファイルが生成されません。
これは、コア ファイル サイズの ulimit が 0 の場合に発生する可能性があります (ulimit -c unlimited を行っていません)。 ) -- これは Ubuntu のデフォルトです。通常、それは「(core dumped)」を抑制し、あなたの間違いを手がかりにしますが、Ubuntuでは、コアファイルは/proc/sys/kernel/core_patternを介してApport（Ubuntuのクラッシュレポートシステム）にパイプされます 、これが誤解を招くメッセージの原因のようです。
Apport が問題のプログラムではないことを発見した場合、クラッシュを報告する必要があります (これは /var/log/apport.log で発生することがわかります) )、コア ファイルを cwd に配置するデフォルトのカーネル動作をシミュレートするようにフォールバックします (これはスクリプト /usr/share/apport/apport で行われます)。 ）。これには、ulimit を尊重することが含まれます。この場合、何もしません。しかし、(私が推測するに) カーネルに関する限り、コアファイルが生成された (そして、apport にパイプされた) ため、"Segmentation fault (core dumped)" というメッセージが表示されました。
最終的には ulimit を設定するのを忘れた PEBKAC でしたが、誤解を招くメッセージが表示されたので、何がコアファイルを食べているのだろうと考えて、しばらく気が狂いそうになりました.
(また、一般に、core(5) マニュアル ページ -- man 5 core -- は、コア ファイルの最終的な場所と、コア ファイルが書き込まれない可能性がある理由の良い参考資料です。)