web-dev-qa-db-ja.com

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

Cプログラムを実行している間、 "（core dumped）"と表示されますが、現在のパスの下にファイルがありません。

ulimitを設定して検証しました。

ulimit -c unlimited 
ulimit -a

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

clinuxcoredump
246
webminal.org

/usr/src/linux/Documentation/sysctl/kernel.txt を読んでください。

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

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

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

いずれにせよ、素早い答えはあなたがあなたのコアファイルを/var/cache/abrtで見つけることができるはずであるということです、そこで、abrtはそれが呼び出された後それを格納します。同様に、 Apport を使用している他のシステムでは、/var/crashのようにコアを追い払う可能性があります。

224
ephemient

最近のUbuntu（私の場合は12.04）では、 "Segmentation fault（core dumped）"が表示される可能性がありますが、期待どおりにコアファイルが生成されないことがあります（たとえばローカルでコンパイルされたプログラムの場合）。

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

問題のプログラムがクラッシュを報告すべきものではないことがApportによって検出された場合（これは/var/log/apport.logで起こっていることがわかります）、デフォルトのカーネルの振る舞いをcwdに入れることになります（これはスクリプト/usr/share/apport/apport）。これはulimitを尊重することを含み、その場合それは何もしません。しかし、（私が思うに）カーネルに関する限り、コアファイルが生成され（そしてapportにパイプされ）、それゆえメッセージ "Segmentation fault（core dumped）"が表示されます。

究極的にはPEBKACは無制限に設定するのを忘れていましたが、誤解を招くメッセージは私がしばらくの間狂っていると思っていました。

（また、一般的に、core（5）マニュアルページ - man 5 core - はあなたのコアファイルがどこで終わるかとそれが書かれないかもしれない理由のための良い参考文献です。）

203
jtn

systemd の発売に伴い、他にもシナリオがあります。デフォルトではsystemdはジャーナルにコアダンプを保存し、systemd-coredumpctlコマンドでアクセス可能になります。 core_patternファイルに定義されています。

$ 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によって行われるように、ダンプされているコアのサイズと同じかそれ以上でなければなりません。

75
timss

Ubuntu 16.04 LTSの下にコアダンプを取得するための命令を書く：

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

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

  3. 今度はあなたのプログラムをもう一度クラッシュさせてください、そしてクラッシュファイルが/ var/crashの中に生成されているのを見てください。*。1000.crash 。これらのファイルはgdbで直接読み取ることはできません。 After making changes

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

    apport-unpack <location_of_report> <target_directory>

参照先： Core_dump - Oracle VM VirtualBox

35
ankurrc

次の2つの可能性が考えられます。

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

  2. 奇妙な理由でコアダンプの名前がcore.*にならないあなたは/proc/sys/kernel/core_patternをチェックすることができます。また、あなたが命名したfindコマンドは典型的なコアダンプを見つけられないでしょう。コアダンプの一般的な名前はfind / -name "*core.*"であるため、core.$PIDを使用する必要があります。

10
ahans

RHEL上のバイナリのコアダンプが見当たらない場合、およびabrtを使用する場合は、必ず/etc/abrt/abrt-action-save-package-data.confを使用してください。

含む

ProcessUnpackaged = yes

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

6
MRalwasser

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

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

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

これは私たちが認識している既知の問題です。調査中のものです。

Githubの問題

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

3
Brandon Søren Culley

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

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

/ proc/sys/kernel/core_patternによるccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P %

3
mahaveer darade

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

0
Nicolas VERHELST