テクノロジー · 実用ガイド
Linux の「Segmentation fault (core dumped)」？再インストール前に crash と binary を一致させる
一回の crash 記録を固定し、実際の core handler を特定して dump を保存し、executable と library の一致を証明してから全 thread を解析します。
「Core dumped」でも current directory に core という file があるとは限りません。Linux は dump を抑止、改名、handler へ pipe、または systemd-coredump で別場所に保存できます。package 変更、反復 restart、rebuild の前に event を保存します。
有効な postmortem には、保存した core、crash した正確な executable byte、mapped library、正しい symbol を一組として照合する必要があります。top frame は停止地点であり、最初の memory corruption 地点とは限りません。
1. system が変わる前に一回の crash を固定
UTC 時刻、command/service、PID、signal、workload、最初の関連 log と service status を保存し、後の artifact を一つの event に結びます。
reinstall、strip、upgrade、executable 置換をまだ行いません。復旧が必要なら binary と library を先に copy/hash し package または container digest を記録します。
2. 実際の core route を特定
crash context の `ulimit -c` と `/proc/sys/kernel/core_pattern` を読みます。`|` で始まる値は pathname ではなく handler です。systemd なら `coredumpctl list` と `info` で時刻、PID、executable を照合します。
`coredumpctl dump PID --output=core.PID` で選択した dump を export するか file を保存し、handler metadata、時刻、signal、retention を記録します。dump がなければ制限 branch を明記し postmortem を捏造しません。
3. core と正確な binary byte を結ぶ
crash した executable を hash し、`readelf -n` で ELF Build ID を記録します。package metadata、container digest、mapped library も保存します。同じ release 名だけでは address の一致を証明できません。
`gdb -q /exact/program core.PID` で明示的に開きます。executable、shared library、symbol の mismatch warning は evidence-integrity failure です。一致する artifact を回収できなければ停止します。
4. frame zero だけでなく全 thread を読む
`info files`、`info sharedlibrary`、`thread apply all bt full`、register、停止命令周辺の disassembly を raw transcript として保存し、symbol の完全性を記します。
SIGSEGV は以前の out-of-bounds write、use-after-free、race の結果かもしれません。top frame は停止地点です。thread、input、ownership、reproduction から仮説を作り、安全なら隔離環境の debug build や sanitizer で検証します。
5. 一仮説だけ直し acceptance を定義
証拠に対応する review 可能な変更を一つ行い、元の core、hash、transcript は不変で保存します。
同じ workload と environment を replay します。期待出力、新しい同種 core なし、安定 health、deployed Build ID 記録が acceptance です。単なる restart は証明になりません。
