☰

分割エラー（コアダンプ） - どこに行くべきですか？それは何ですか？なぜ？

tag-icon • tag-icon segmentation-fault core-dump
分割エラー（コアダンプ） - どこに行くべきですか？それは何ですか？なぜ？

Linuxで分割エラーが発生すると、エラーメッセージがSegmentation fault (core dumped)端末（存在する場合）に印刷され、プログラムが終了します。これはC / C ++開発者として頻繁に発生し、通常はこれを無視して続行し、gdb誤ったメモリ参照が再起動されるように前の操作を再作成します。代わりに、常に実行するのgdbはやや退屈で、分割エラーを常に再現することはできないので、この「コア」を使用できると思いました。

私の質問は3つあります。

  • この探しにくい「核心」はどこに捨てられましたか？
  • それは何を含んでいますか？
  • それで何ができますか？

答え1

他人が掃除したら…

...通常何も見つかりません。ただし、幸いなことに、Linuxには実行時に指定できるハンドラがあります。存在する/usr/src/linux/Documentation/sysctl/kernel.txtあなたは見つけるでしょう：

core_patternコアダンプファイルモード名を指定するために使用されます。

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

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

ソースによると、これはabrtプログラム的に処理されますが（つまり、中断ではなく自動エラー報告ツール）、私のArch Linuxではsystemdによって処理されます。独自のハンドラを作成するか、現在のディレクトリを使用できます。

しかし、中には何がありますか？

ここに含まれる内容はシステムごとに異なりますが、以下に基づいています。すべてを知る百科事典:

[コアダンプ]は、特定の時間[...]にコンピュータプログラムワークメモリの記録された状態で構成されます。実際には、プログラムカウンタとスタックポインタ、メモリ管理情報、他のプロセッサとオペレーティングシステムのフラグと情報を含むことができるプロセッサレジスタを含む、プログラム状態の他の重要な部分が同時にダンプされることがよくあります。

...これには、基本的にgdb失敗を分析するために必要なすべてが含まれています（失敗を引き起こした実行可能ファイルを除く）。

うん、でもgdbの代わりに幸せだったらいいな

gdb実行可能ファイルの正確なコピーがある限り、すべてのコアダンプがロードされるため、すべて満足できますgdb path/to/binary my/core.dump。これにより、エラーを再現しようとし、失敗するのではなく特定のエラーを分析できるはずです。

答え2

また、ulimit -c返されると0コアダンプファイルは書き込まれません。

バラよりLinuxアプリケーションのクラッシュによって生成されたコアファイルをどこで検索できますか？

CTRL- を使用して手動でコアダンプを実行することもできます。\これでプロセスが終了し、コアダンプが発生します。

答え3

コアファイルは通常、coreプロセスの現在の作業ディレクトリに呼び出され、配置されます。ただし、コアファイルを生成できない理由はいくつかあり、ファイルが別の名前でまったく異なる場所にある可能性があります。よりcore.5 マニュアルページ詳細：

説明する

いくつかの信号の基本的な動作は、プロセスを終了し、次を生成することです。コアダンプファイル、プロセスが終了したときにメモリイメージを含むディスクファイル。このイメージはデバッガ（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

答え4

Ubuntuでは、発生したすべての競合がに記録されます/var/crash。生成された競合レポートは、次のツールを使用して解凍できますapport。

apport-unpack /var/crash/_crash_file.crash <path to unpack>

解凍レポートのコアダンプは、次のように読み取ることができます。

gdb "$(cat ExecutablePath)" CoreDump

関連情報