Linuxでセグメンテーション違反が発生すると、エラーメッセージSegmentation fault (core dumped)
がターミナルに出力され(存在する場合)、プログラムが終了します。 C/C++開発者として、これはかなり頻繁に発生し、私は通常それを無視してgdb
に移動し、無効なメモリ参照を再度トリガーするために前のアクションを再作成します。代わりに、私はおそらくこの「コア」を代わりに使用できるかもしれないと思っていました。常にgdb
を実行するのは面倒で、常にセグメンテーションフォールトを再現できるとは限らないからです。
私の質問は3つです。
...通常、何も見つかりません。しかし、幸運なことにLinuxには、実行時に指定できるハンドラーがあります。 / usr/src/linux/Documentation/sysctl/kernel.txt には、
[/ proc/sys/kernel /] core_patternは、コアダンプファイルのパターン名を指定するために使用されます。
- パターンの最初の文字が '|'の場合、カーネルは残りのパターンを実行するコマンドとして扱います。コアダンプは、ファイルではなく、そのプログラムの標準入力に書き込まれます。
( ありがとう )
ソースによると、これはabrt
プログラム(自動バグ報告ツールで、中止ではありません)によって処理されますが、私のArch Linuxではsystemdによって処理されます。独自のハンドラーを作成するか、現在のディレクトリを使用できます。
これに含まれるものはシステム固有ですが、 全知の百科事典 によると:
[コアダンプ]は、特定の時間におけるコンピュータプログラムの作業メモリの記録された状態で構成されます[...]。実際には、プログラムカウンタとスタックポインタ、メモリ管理情報、その他のプロセッサとオペレーティングシステムのフラグと情報を含むプロセッサレジスタなど、他の主要なプログラム状態が通常同時にダンプされます。
...基本的に、これにはgdb
に必要なものがすべて含まれています。
実行可能ファイルの正確なコピーがある限り、gdb
はコアダンプをロードするので、どちらも満足できます:gdb path/to/binary my/core.dump
。これで、通常どおりビジネスを継続でき、バグの再現に失敗するのではなく、バグの修正に失敗することに悩まされるはずです。
また、ulimit -c
戻り値 0
の場合、コアダンプファイルは書き込まれません。
Linuxアプリケーションのクラッシュによって生成されたコアファイルを検索する場所は? を参照してください。
手動でコアダンプをトリガーすることもできます CTRL-\ これによりプロセスが終了し、コアダンプが発生します。
コアファイルは通常core
と呼ばれ、プロセスの現在の作業ディレクトリにあります。ただし、コアファイルが生成されない理由の長いリストがあり、別の名前で完全に別の場所に配置される場合があります。詳細は core.5 man page を参照してください:
説明
特定のシグナルのデフォルトアクションは、プロセスを終了させ、コアダンプファイル、プロセスのイメージを含むディスクファイルを生成することです終了時のメモリ。このイメージをデバッガー(たとえば、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フラグが使用されている場合、コアダンプはプロセスのアドレス空間の一部を除外する可能性があります。
コアダンプファイルの命名
デフォルトでは、コアダンプファイルの名前はcoreですが、/ 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を使用して解凍できます
apport-unpack /var/crash/_crash_file.crash '解凍するパス'
解凍したレポートのコアダンプは、
gdb 'cat ExecutablePath' CoreDump