コアダンプされましたが、コアファイルは現在のディレクトリにありませんか？

Cプログラムの実行中に「（コアダンプ）」と表示されますが、現在のパスの下にファイルが表示されません。

私は設定して確認しましたulimit：

ulimit -c unlimited 
ulimit -a 

「core」という名前のファイルも見つけようとしましたが、コアダンプファイルを取得できませんでしたか？
私のコアファイルはどこにありますか？

/usr/src/linux/Documentation/sysctl/kernel.txtを読みます。

[/ proc / sys / kernel /] core_patternは、コアダンプファイルのパターン名を指定するために使用されます。

• パターンの最初の文字が '|'の場合、カーネルはパターンの残りの部分を実行するコマンドとして扱います。コアダンプは、ファイルではなく、そのプログラムの標準入力に書き込まれます。

コアダンプをディスクに書き込む代わりに、システムはそれをabrtプログラムに送信するように構成されています。 自動化されたバグ報告ツールは、おそらく文書化されていないはずです...

いずれの場合も、迅速な答えは、あなたがあなたのコアファイルを見つけることができるはずということである/var/cache/abrtところ、abrt格納呼び出された後。同様に、Apportを使用する他のシステムは/var/crash、のコアをリスで削除する場合があります。

最近のUbuntu（私の場合は12.04）では、「セグメンテーション違反（コアダンプ）」が出力される可能性がありますが、コアファイルが期待どおりに生成されません（たとえば、ローカルでコンパイルされたプログラムの場合）。

これは、コアファイルサイズulimitが0の場合（まだ行っていない場合）に発生する可能性ulimit -c unlimitedがあります-これはUbuntuのデフォルトです。通常、それはあなたの間違いにあなたをcluing、「（コアダンプ）」抑制するだろうが、Ubuntuの上で、コアファイルがにパイプされApport経由（Ubuntuのクラッシュ報告システム）/proc/sys/kernel/core_pattern、これは誤解を招くメッセージを引き起こしているようです。

Apportが問題のプログラムがクラッシュを報告する必要のあるプログラムではないことを発見した場合（これはで発生することがわかります/var/log/apport.log）、コアファイルをCWDに配置するデフォルトのカーネル動作のシミュレーションにフォールバックします（これはスクリプトで行われます）/usr/share/apport/apport）。これには、ulimitを尊重することも含まれます。しかし（私はそう思います）カーネルに関する限り、corefileが生成され（そしてapportにパイプで送られ）、したがって「セグメンテーション違反（コアダンプ）」というメッセージが表示されます。

最終的にPEBKACはulimitの設定を忘れたためですが、この誤解を招くメッセージにより、しばらくの間、自分のコアファイルを何が食べているのかと気が狂ったように思いました。

（また、一般的には、core（5）のマニュアルページman 5 core--は、コアファイルがどこに行き着くか、およびコアファイルが書き込まれない理由についての優れたリファレンスです。）

systemdのリリースに伴い、別のシナリオもあります。デフォルトでは、systemdはコアダンプをジャーナルに保存し、systemd-coredumpctlコマンドでアクセスできます。core_pattern-fileで定義：

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

この動作は、単純な「ハック」で無効にできます。

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

いつものように、コアダンプのサイズは、たとえばによって行われるように、ダンプされているコアのサイズ以上である必要がありますulimit -c unlimited。

Ubuntu 16.04 LTSでコアダンプを取得するための手順を書く：

1. @jtnが彼の回答で述べたように、Ubuntuはクラッシュの表示をapportに委任し、プログラムはインストールされたパッケージではないため、ダンプの書き込みを拒否します。

2. この問題を解決するには、apportがパッケージ以外のプログラムのコアダンプファイルも書き込むようにする必要があります。これを行うには、以下の内容で〜/ .config / apport / settingsという名前のファイルを作成します。
   [main] unpackaged=true

3. 次に、プログラムを再度クラッシュさせて、*。1000.crashのような名前のフォルダー/ var / crash内に生成されたクラッシュファイルを確認します。これらのファイルはgdbから直接読み取ることができないことに注意してください。

4. [オプション]ダンプをgdbで読み取り可能にするには、次のコマンドを実行します。

   apport-unpack <location_of_report> <target_directory>

参照： Core_dump – Oracle VM VirtualBox

次の2つの可能性を考えることができます。

1. 他の人がすでに指摘したように、プログラムはそうかもしれませんchdir()。プログラムを実行しているユーザーは、移動先のディレクトリへの書き込みを許可されchdir()ていますか？そうでない場合は、コアダンプを作成できません。

2. 奇妙な理由で、コアダンプの名前が表示されません。それcore.*を確認でき/proc/sys/kernel/core_patternます。また、指定したfindコマンドでは、一般的なコアダンプは見つかりません。あなたは使うべきfind / -name "*core.*"コアダンプの代表的な名前があるとして、core.$PID

のRHEL使用時にバイナリのコアダンプが見つからない場合はabrt、/etc/abrt/abrt-action-save-package-data.conf

含む

ProcessUnpackaged = yes

これにより、インストールされたパッケージの一部ではないバイナリ（ローカルでビルドされたものなど）のクラッシュレポート（コアダンプを含む）を作成できます。

fedora25の場合、コアファイルは次の場所にあります

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

ここでccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P %、 `/ proc / sys / kernel / core_pattern 'に従って

WSLでの私の取り組みは成功していません。

Linux（WSL）のWindowsサブシステムで実行している場合、現時点でコアダンプファイルが見つからないという未解決の問題があるようです。

コメントはそれを示しています

これは既知の問題であり、現在調査中です。

Githubの問題

Windows開発者のフィードバック

Ubuntu18.04では、コアファイルを取得する最も簡単な方法は、apportサービスを停止するために以下のコマンドを入力することです。

sudo service apport stop

次に、アプリケーションを再実行すると、現在のディレクトリにダンプファイルが作成されます。

私はLinux Mint 19（Ubuntu 18ベース）を使用しています。coredump現在のフォルダにファイルを置きたかった。私は2つのことをしなければなりませんでした：

1. 変更/proc/sys/kernel/core_pattern（# echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_patternまたは# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
2. コアファイルサイズの制限を引き上げる $ ulimit -c unlimited

それはすでに回答に書かれていましたが、私は簡潔に要約するために書きました。興味深いことに、制限を変更してもroot権限は必要ありませんでした（/ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- rootは制限を下げることしかできないので、それは予想外でした-それに関するコメントは大歓迎です）。

ulimit -c unlimited 「コアダンプ」後にコアファイルが現在のディレクトリに正しく表示されるようにしました。