Linuxでセグメンテーション違反が発生すると、エラーメッセージSegmentation fault (core dumped)が端末に出力されます（存在する場合） ）、プログラムは終了します。 C / C ++開発者として、これは非常に頻繁に発生します。通常、これを無視してgdbに移動し、無効なメモリ参照を再度トリガーするために以前のアクションを再作成します。代わりに、gdbを常に実行するのはかなり面倒で、セグメンテーション違反を常に再現できるとは限らないため、代わりにこの「コア」を使用できるかもしれないと思いました。
私の質問は3つです：
- このとらえどころのない「コア」はどこにダンプされますか？
- 何が含まれていますか？
- 何ができますか
コメント
回答
他の人がクリーンアップした場合…
…通常は何も見つかりません。しかし幸いなことにLinuxには実行時に指定できるこのハンドラー。 /usr/src/linux/Documentation/sysctl/kernel.txt には、次のものがあります。
[/ proc / sys / kernel /] core_patternは、コアダンプファイルのパターン名を指定するために使用されます。
- の最初の文字がパターンが「|」の場合、カーネルはパターンの残りの部分を実行するコマンドとして扱います。コアダンプは、ファイルではなく、そのプログラムの標準入力に書き込まれます。
（ありがとう）
Aソースによると、これはabrtプログラム（自動バグ報告ツール、中止ではありません）によって処理されますが、私のArchLinuxではsystemdによって処理されます。独自のハンドラーを作成するか、現在のディレクトリを使用することをお勧めします。
しかし、そこには何がありますか？
これで、含まれるものはシステム固有ですが、すべてを知っている百科事典：
[コアダンプ]は、作業メモリの記録された状態で構成されます特定の時間におけるコンピュータプログラムの[…]。実際には、プログラムカウンタとスタックポインタ、メモリ管理情報、メモリ管理情報などのプロセッサレジスタを含む、プログラム状態の他の重要な部分が通常同時にダンプされます。およびその他のプロセッサとオペレーティングシステムのフラグと情報。
…したがって、基本的にすべてのgdbが含まれます。
ええ、でも私はgdbの代わりに幸せになりたいです
gdb実行可能ファイルの正確なコピーがある限り、コアダンプをロードします：gdb path/to/binary my/core.dump。そうすれば、通常どおりビジネスを継続でき、バグの再現を試みて失敗するのではなく、バグの修正を試みて失敗することに悩まされるはずです。
回答
また、ulimit -cが0を返す場合、コアダンプファイルは書き込まれません。
Linuxアプリケーションのクラッシュによって生成されたコアファイルを検索する場所を参照してください。
また、 CTRL – \ を使用してコアダンプを手動でトリガーすると、プロセスが終了してコアダンプが発生します。
回答
コアファイルは通常coreと呼ばれ、プロセスの現在の作業ディレクトリにあります。ただし、コアファイルが生成されない理由は多数あり、完全に別の場所に別の名前で配置されている可能性があります。詳細については、 core.5のマニュアルページを参照してください：
説明
特定のシグナルのデフォルトのアクションは、プロセスを終了させ、コアダンプファイル、 aを生成することです。終了時のプロセスのメモリのイメージを含むディスクファイル。このイメージは、デバッガー（gdb（1）など）で使用して、終了時のプログラムの状態を検査できます。プロセスがコアをダンプする原因となるシグナルのリストはsignal（7）にあります。
…
さまざまなものがありますコアダンプファイルが生成されない状況：
* The process does not have permission to write the core file. (By default, the core file is called core or core.pid, where pid is the ID of the process that dumped core, and is created in the current working directory. See below for details on naming.) Writing the core file will fail if the directory in which it is to be created is nonwritable, or if a file with the same name exists and is not writable or is not a regular file (e.g., it is a directory or a symbolic link). * A (writable, regular) file with the same name as would be used for the core dump already exists, but there is more than one hard link to that file. * The filesystem where the core dump file would be created is full; or has run out of inodes; or is mounted read-only; or the user has reached their quota for the filesystem. * The directory in which the core dump file is to be created does not exist. * The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size) resource limits for the process are set to zero; see getrlimit(2) and the documentation of the shell"s ulimit command (limit in csh(1)). * The binary being executed by the process does not have read permission enabled. * The process is executing a set-user-ID (set-group-ID) program that is owned by a user (group) other than the real user (group) ID of the process, or the process is executing a program that has file capabilities (see capabilities(7)). (However, see the description of the prctl(2) PR_SET_DUMPABLE operation, and the description of the /proc/sys/fs/suid_dumpable file in proc(5).) * (Since Linux 3.7) The kernel was configured without the CONFIG_COREDUMP option.さらに、madvise（）の場合、コアダンプはプロセスのアドレススペースの一部を除外する可能性があります。 2）MADV_DONTDUMPフラグが採用されました。
コアダンプファイルの名前付け
デフォルトでは、コアダンプファイル はコアという名前ですが、/ proc / sys / kernel / core_patternファイル（Linux 2.6および2.4.21以降）を設定して、コアダンプファイルに名前を付けるために使用されるテンプレートを定義できます。 テンプレートには、コアファイルの作成時に次の値に置き換えられる％指定子を含めることができます。
%% a single % character %c core file size soft resource limit of crashing process (since Linux 2.6.24) %d dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE (since Linux 3.7) %e executable filename (without path prefix) %E pathname of executable, with slashes ("/") replaced by exclamation marks ("!") (since Linux 3.0). %g (numeric) real GID of dumped process %h hostname (same as nodename returned by uname(2)) %i TID of thread that triggered core dump, as seen in the PID namespace in which the thread resides (since Linux 3.18) %I TID of thread that triggered core dump, as seen in the initial PID namespace (since Linux 3.18) %p PID of dumped process, as seen in the PID namespace in which the process resides %P PID of dumped process, as seen in the initial PID namespace (since Linux 3.12) %s number of signal causing dump %t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC) %u (numeric) real UID of dumped process
回答
Ubuntuでは、発生したクラッシュはすべて/ var / crashに記録されます。 生成されたクラッシュレポートは、ツールapport
appport-unpack /var/crash/_crash_file.crash “path tounpack”を使用して解凍できます
次に、解凍されたレポートのコアダンプは、
gdb “catを使用して読み取ることができます。 ExecutablePath “CoreDump
gdb path-to-your-binary path-to-corefileだけです。次にinfo stackの後にCtrl-dが続きます。唯一心配なのは、コアダンプが通常のことであるということです。