Tecnología · GUÍA PRÁCTICA
¿Linux dice “Segmentation fault (core dumped)”? Conserva el fallo y empareja el binario antes de reinstalar
Congela un fallo, localiza el handler real, conserva el core, demuestra que executable y libraries coinciden, analiza todos los threads y valida con la misma carga.
“Core dumped” no garantiza un archivo llamado core en el directorio actual. Linux puede suprimirlo, renombrarlo, enviarlo por pipe a un handler o dejar que systemd-coredump lo conserve en otro lugar. Preserva el evento antes de cambiar paquetes, reiniciar o recompilar.
Un postmortem útil exige un conjunto coincidente: core retenido, bytes exactos del executable que falló, libraries mapeadas y símbolos correctos. El frame superior indica dónde se detuvo la ejecución, no necesariamente dónde comenzó la corrupción.
1. Congela un fallo antes de que cambie el sistema
Registra hora UTC, comando o servicio, PID, signal, workload, primeros logs y estado del servicio. Así, los artefactos posteriores pertenecen a un solo evento.
No reinstales, elimines símbolos, actualices ni reemplaces el executable. Si debes restaurar el servicio, copia y calcula el hash del binario y sus libraries, y registra el package o container digest.
2. Resuelve la ruta real del core
Lee `ulimit -c` en el contexto que falla y `/proc/sys/kernel/core_pattern`. Un valor que empieza con `|` es un handler, no un pathname. Con systemd, usa `coredumpctl list` e `info` para elegir por tiempo, PID y executable.
Exporta con `coredumpctl dump PID --output=core.PID` o conserva el archivo literal. Registra metadata del handler, hora, signal y retención. Si no existe dump, documenta la limitación y corrige la captura antes de afirmar un postmortem.
3. Vincula el core con bytes exactos
Calcula el hash del executable y registra el ELF Build ID con `readelf -n`. Conserva package metadata, container digest y libraries mapeadas. “Misma versión” no demuestra direcciones idénticas.
Abre `gdb -q /exact/program core.PID`. Trata avisos de executable, shared libraries o símbolos incompatibles como fallos de integridad. Recupera los artefactos exactos o detente.
4. Lee todos los threads, no solo frame cero
Conserva `info files`, `info sharedlibrary`, `thread apply all bt full`, registros y disassembly alrededor de la instrucción. Anota si los símbolos están completos, parciales o ausentes.
SIGSEGV puede ser consecuencia de un out-of-bounds write, use-after-free o race anterior. El top frame prueba el punto de parada. Formula una hipótesis con threads, input, ownership y reproducción; usa debug build o sanitizer solo en un entorno aislado.
5. Repara una hipótesis y define aceptación
Haz un cambio revisable ligado a la evidencia y conserva inmutables el core, hashes y transcript originales.
Repite el mismo workload y environment. Exige salida esperada, ningún core nuevo equivalente, salud estable y Build ID desplegado registrado. Un reinicio que oculta el mensaje no demuestra la reparación.
