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。これにより、エラーを再現しようとし、失敗するのではなく特定のエラーを分析できるはずです。