科技 · 實用指南
Linux 顯示「Segmentation fault (core dumped)」？重裝前先保存崩潰並比對執行檔
凍結一次崩潰記錄，找到實際 core 處理器，保存轉儲，證明執行檔與函式庫完全相符，再分析所有執行緒並用相同負載驗收修復。
「Core dumped」不等於目前目錄一定有名為 core 的檔案。Linux 可能抑制轉儲、改名、透過管線交給處理器，或由 systemd-coredump 保存於其他位置。更換套件、反覆重啟或重建前先保存事件。
可靠的事後分析需要同一套相符證據：保存的 core、發生崩潰的精確執行檔位元、映射函式庫與正確符號。最上層 frame 只是執行停止位置，不一定是記憶體最初被破壞的位置。
1. 系統變更前凍結一次崩潰
記錄 UTC 時間、命令或服務、PID、信號、工作負載與第一段相關日誌，保存精確訊息和服務狀態，把後續製品綁定至同一事件。
暫不重裝、strip、升級或替換執行檔。若必須恢復服務，先複製並雜湊執行檔與相關函式庫，記錄套件或容器摘要。
2. 確認實際 core 路徑
在崩潰情境讀取 `ulimit -c` 與 `/proc/sys/kernel/core_pattern`。以 `|` 開頭的是處理器而非路徑；systemd 環境用 `coredumpctl list` 與 `info` 依時間、PID、執行檔選取記錄。
以 `coredumpctl dump PID --output=core.PID` 匯出或保存原檔，同時記錄處理器中繼資料、時間、信號與保存狀態。沒有轉儲就寫明限制分支，不能虛構事後分析。
3. 將 core 綁定至精確執行檔
雜湊崩潰程式並用 `readelf -n` 記錄 ELF Build ID；保存套件、容器摘要與映射函式庫。「版本名稱相同」不足以證明位址相同。
用 `gdb -q /exact/program core.PID` 明確載入。若出現執行檔、共享函式庫或符號不相符警告，視為證據完整性失敗；找回相符製品，否則停止。
4. 分析所有執行緒而非只看 frame 0
保存 `info files`、`info sharedlibrary`、`thread apply all bt full`、暫存器和停止指令附近反組譯，註明符號完整、部分或缺失。
SIGSEGV 可能源自更早的越界寫入、use-after-free 或競態。最上層 frame 只證明停止點；結合執行緒、輸入、所有權與重現性提出假設，安全時於隔離環境用 debug build 或 sanitizer。
5. 只修一個假設並定義驗收
做一項由證據支持且可審查的修改，保持原 core、雜湊與記錄不變以利前後比較。
用相同工作負載與環境重播。驗收要求輸出正確、沒有新的同類 core、服務穩定且記錄部署 Build ID；只重啟後暫時不報錯不算證明。
