Core dump

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Domaine Diagnostic post-mortem (crash process)
Commande ulimit -c, gdb
Contexte Shell (bash) + noyau (/proc/sys/kernel/core_pattern)
Voir aussi Ulimit (activation), Strace/ABRT (diagnostic)

Un core dump est un fichier contenant l'image mémoire d'un process au moment d'un crash (segfault, signal fatal...). Il permet une analyse post-mortem avec gdb pour retrouver la pile d'appels et la cause de l'erreur, sans avoir à reproduire le bug en direct.

Activer la génération de core dumps

Par défaut, la plupart des distributions désactivent les cores (limite à 0). Il faut lever la limite via ulimit, au niveau shell ou système :

ulimit -c unlimited          # sans limite, pour la session shell courante
ulimit -c 10240              # limite en Ko (ici ~10 Mo)
ulimit -c                    # afficher la limite actuelle

Pour rendre ce réglage permanent (tous les utilisateurs, toutes les sessions), passer par PAM :

# /etc/security/limits.conf
*               soft    core            unlimited

Voir Ulimit pour le détail des limites soft/hard et leur persistance.

Emplacement et nom du fichier core

Le noyau contrôle où et sous quel nom les cores sont écrits via /proc/sys/kernel/core_pattern :

cat /proc/sys/kernel/core_pattern
echo '/tmp/core-%e-%p-%t' > /proc/sys/kernel/core_pattern   # test à chaud, non persistant

# persistant, via sysctl
# /etc/sysctl.conf
kernel.core_pattern = /tmp/core-%e-%p-%t

Quelques specifiers utiles dans le pattern : %e (nom de l'exécutable), %p (PID), %t (timestamp), %s (signal). Si core_pattern commence par un |, le noyau redirige le core vers un programme (c'est le mécanisme utilisé par ABRT pour capter automatiquement les crashs).

Analyser un core avec gdb

gdb /chemin/vers/executable core-fichier
(gdb) bt              # backtrace : pile d'appels au moment du crash
(gdb) info registers   # état des registres CPU
(gdb) quit

Prérequis : le binaire analysé doit correspondre exactement à celui qui a généré le core (mêmes symboles), sinon la backtrace est inexploitable. Compiler avec les symboles de debug (-g) ou installer le paquet de debuginfo correspondant améliore nettement la lisibilité.

Désactiver les core dumps

Utile en production pour éviter de saturer le disque avec des cores volumineux, une fois le diagnostic terminé.

Par utilisateur, via PAM :

# /etc/security/limits.conf
*               hard    core            0

Au niveau système, pour empêcher un utilisateur d'augmenter lui-même sa propre limite (la limite hard PAM ne suffit pas seule à protéger les binaires setuid) :

echo 'fs.suid_dumpable = 0' >> /etc/sysctl.conf
sysctl -p

Et pour couper explicitement la génération côté shell (profil global) :

# /etc/profile
ulimit -S -c 0 > /dev/null 2>&1

Voir aussi

  • Ulimit — détail des limites de ressources (soft/hard, persistance PAM)
  • Strace — tracer les appels système d'un process vivant, complémentaire à l'analyse post-mortem d'un core
  • ABRT — capture et rapport automatique des crashs (utilise core_pattern en coulisse)