セグメンテーションフォールト(コアダンプ)-どこへ?それは何ですか?なぜ?


16

Linuxでセグメンテーションエラーが発生すると、エラーメッセージSegmentation fault (core dumped)が端末(ある場合)に出力され、プログラムが終了します。C / C ++開発者として、これは非常に頻繁に起こります。通常、それを無視してに進みgdb、無効なメモリ参照を再度トリガーするために以前のアクションを再作成します。代わりに、私はおそらくこの「コア」を代わりに使用できるかもしれないと考えgdbました。なぜなら、常に実行するのはかなり退屈であり、セグメンテーション違反を常に再現できるわけではないからです。

私の質問は3つです。

  • このとらえどころのない「コア」はどこに捨てられますか?
  • 何が含まれていますか?
  • 私はそれで何ができますか?

通常gdb path-to-your-binary path-to-corefile、必要なのはコマンドのみで、info stackその後にCtrl-d。唯一心配なのは、コアダンプが通常のことだということです。
-ott--

それほど一般的ではなく、時折 -ほとんどの場合、タイプミスまたは何かを変更し、結果を先取りしなかったことが原因です。
ジョー

回答:


16

他の人が片付ければ......

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

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

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

ありがとう

ソースによると、これはabrtプログラムによって処理されます(それは自動バグ報告ツールであり、中止ではありません)が、私のArch Linuxではsystemdによって処理されます。独自のハンドラを記述するか、現在のディレクトリを使用することもできます。

しかし、そこには何がありますか?

今含まれているものはシステム固有ですが、すべての知識百科事典によると:

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

...そのため、基本的にgdbこれまでに求められていたものすべてが含まれています。

うん、でもgdbの代わりに幸せになって欲しい

gdb実行可能ファイルの正確なコピーがある限り、コアダンプがロードされるため、どちらも満足できますgdb path/to/binary my/core.dump。その後、通常どおりビジネスを継続し、バグを再現しようとするのではなく、バグを修正しようとすることに失敗することに悩まされるはずです。



4

コアファイルは通常呼び出され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

1

Ubuntuでは、発生したクラッシュは/ var / crashに記録されます。生成されたクラッシュレポートは、ツールアポートを使用して展開できます。

apport-unpack /var/crash/_crash_file.crash 'アンパックするパス'

そして、アンパックされたレポートのコアダンプは、次を使用して読み取ることができます。

gdb 'cat ExecutablePath' CoreDump

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.