Segmentation-Fault
分段錯誤（核心轉儲） - 到哪裡？它是什麼？為什麼？
當 Linux 中發生分段錯誤時，錯誤資訊
Segmentation fault (core dumped)將被列印到終端（如果有），程序將被終止。作為一名 C/C++ 開發人員，這種情況經常發生在我身上，我通常會忽略它並繼續前進gdb，重新創建我之前的操作以再次觸發無效的記憶體引用。相反，我認為我也許可以使用這個“核心”，因為一直執行gdb是相當乏味的，而且我不能總是重新創建分段錯誤。我的問題是三個：
- 這個難以捉摸的“核心”扔到哪裡去了？
- 它包含什麼？
- 我能用它做什麼？
如果其他人清理…
…你通常什麼都找不到。但幸運的是，Linux 有一個處理程序，您可以在執行時指定它。在/usr/src/linux/Documentation/sysctl/kernel.txt你會發現：
core_pattern用於指定核心轉儲文件模式名稱。
- 如果模式的第一個字元是“|”，核心會將模式的其餘部分視為要執行的命令。核心轉儲將被寫入該程序的標準輸入而不是文件。
（參見核心轉儲，但核心文件不在目前目錄中？在 StackOverflow 上）
根據消息來源，這是由
abrt程序處理的（即自動錯誤報告工具，而不是中止），但在我的 Arch Linux 上，它由 systemd 處理。您可能想要編寫自己的處理程序或使用目前目錄。但是裡面有什麼？
現在它包含的是系統特定的，但根據眾所周知的百科全書：
$$ A core dump $$由電腦程序的工作記憶在特定時間的記錄狀態組成$$ … $$. 在實踐中，通常會同時轉儲其他關鍵的程序狀態，包括處理器寄存器，其中可能包括程序計數器和堆棧指針、記憶體管理資訊以及其他處理器和作業系統標誌和資訊。
…所以它基本上包含分析故障所需的一切
gdb（除了導致故障的執行檔）。是的，但我希望我快樂而不是 gdb
gdb只要您擁有執行檔的精確副本，您就會感到高興，因為將載入任何核心轉儲：gdb path/to/binary my/core.dump. 然後，您應該能夠分析特定的故障，而不是嘗試重現錯誤並失敗。