シナリオ (Ubuntu 16.04):
C プログラムをコンパイルして実行すると ( を使用) -g、従来の が表示されSegmentation Fault (core dumped)、(もちろん) 架空の「コア」ファイルは見つかりません。調べてみると、/proc/sys/kernel/core_patternという効果のコマンドを使用して を変更するとよいとのecho '|tee /home/me/my_core_folder/my_core_file' | sudo tee /proc/sys/kernel/core_patternことで、これを実行すると、 が(core dumped)表示されなくなり、プレーンな のみが表示されるようになりますSegmentation Fault。 明らかに存在しない などのコマンドを試しgdb ./program_object_file.out core.pid(必死になっていました)、プレーンgdb ./a.outな に続いて(gdb) core core.pidや コマンドのバリエーションを試しtab、必死になってキーを連打して自動補完によって目的の場所にたどり着こうとします。
質問：
コアダンプを取得する一般的な方法はありますか？私が触ったマシンはすべて、マイケル・ベイのトランスフォーマーハードウェアとソフトウェアを再構成する機能があり、所有するデバイスがすぐに正常に動作することは期待できません。自分のマシンだけでなく他の人のマシンでもコア ダンプを見つけるための簡単なアルゴリズムやレシピはありますか? 自分で動作させるのにかなりの労力を費やした後、いつも友人にこのようなことを指導しています。実行ファイルが実行されたディレクトリにコア ファイルをダンプするコマンドなどを実行できれば便利です... ほとんどの (「一部」で十分です) Linux/Unix マシンで機能する方法はありますか?
答え1
のcore(5)man ページでは、コア ダンプに影響するパラメータについて、その名前付けなどを含めて詳細に説明しています。
あなたの質問に答えると、コアダンプを見つけるための一般的な方法はありません。デフォルトでは、コアはプロセスの現在の作業ディレクトリ、プロセスがそこに書き込みを許可されているかどうか、格納されているファイルシステムに十分なスペースがあるかどうか、既存のコアダンプがないかどうか (状況によっては)、ファイルサイズとコアファイルサイズの制限 (またはulimit同様のメカニズムによって設定されている) がそれを許可するかどうかを確認します。ただし、/proc/sys/kernel/core_patternコアダンプを処理するさまざまな方法が提供されているため、実際にそれを確認して何が起こっているかを把握する必要があります。
あなたの場合、なぜ最初にコアが見つからなかったのかはわかりませんが、リダイレクトを設定した後にコアが取得されなくなった理由はわかっています。パイプを使用するとcore_pattern、処理プログラムしなければならない絶対パス名を使用して指定する必要があります。teeは単独では使用されない為、 を指定する必要があります/usr/bin/tee。コアダンプを処理するために実行されるプログラムは として実行されるため、マルチユーザーシステムでのこのタイプのセットアップには特に注意する必要があることに注意してくださいroot。
Debian派生版ではインストールするcorekeeperは、コア ダンプを の下にあるユーザーごとのディレクトリに簡単に使用できる方法で書き込みます/var/crash。
答え2
(質問内の OP からの回答を回答に移動する)
実際に何が問題なのかを特定するのに役立ったので、以下の回答を正解としてマークしました。将来的には、この件についてもう少し詳しく説明するために戻ってきたいと思っていますが、現在の解決策（ほとんどの Linux マシンで機能すると思われます）は、次のコマンドを使用することです。
cat /proc/sys/kernel/core_pattern > ~/.core_pattern.bak
echo '|/usr/bin/tee ~/path_you_wish_to_dump_to/core/dump' | sudo tee /proc/sys/kernel/core_pattern
これにより、以前のコアダンプ方法が.core_pattern.bakホームフォルダ内の隠しファイル（ ）にバックアップされ、次のように復元できます。
sudo cp ~/.core_pattern.bak /proc/sys/kernel/core_pattern
2 番目のコマンドを実行すると、コア ダンプが という名前のフォルダーにcoreファイルとしてダンプされますdump。もちろん、この形式をいじって、好みのパターンにすることができます。ただし、私が知る限り、これは一度に 1 つのコア ダンプのみを保存します (新しいコア ダンプごとに古いコア ダンプが上書きされます)。ただし、個人的にコア ダンプを確認する場合は、実行したばかりのプログラムのコア ダンプであり、古いダンプを保持する必要がないため、これは私にとって、また友人が作成してデバッグするほとんどのアプリケーションにとって適切なソリューションです。今後、この回答をもう少し変更して、セグメント違反の原因となった PID などを含めたいと思います (繰り返しますが、通常はどのプログラムがセグメント違反の原因となったかは実行したばかりなのでわかっているので、ほとんどは単なるおまけです)。しかし、私にとっては、そしておそらく多くの人にとって、これで十分でしょう。
最後に、実際にダンプを表示するには、次のコマンドを実行するだけです。
gdb ./executable_that_crashed ~/path_you_wish_to_dump_to/core/dump
セグメント違反が発生している実行可能ファイルをコンパイル/実行したフォルダーにいると仮定します。