Erreurs

❌ Erreur Linux "Segmentation fault" — Causes et Solutions

🐧 Erreur Linux

Violation d'accès mémoire — processus arrêté par le noyau

🐧 Linux 📋 6 causes 🔧 5 solutions
Un Segmentation fault (SIGSEGV, signal 11) se produit quand un processus tente d'accéder à une zone mémoire non autorisée. Le noyau Linux arrête immédiatement le processus. C'est souvent le signe d'un bug logiciel, de librairies corrompues ou d'une RAM défectueuse.

⚠️ Causes possibles

⚠️
Bug dans le code
Déréférencement de pointeur NULL, buffer overflow, use-after-free
⚠️
Librairies corrompues ou incompatibles
Mises à jour partielles, librairies .so manquantes ou wrongversion
⚠️
RAM défectueuse
Erreurs mémoire physiques provoquant des corruptions
⚠️
Pile trop petite
Récursion infinie ou très profonde dépassant la stack size
⚠️
Variables d'environnement incorrectes
LD_PRELOAD ou LD_LIBRARY_PATH incorrects
⚠️
Fichier binaire corrompu
Téléchargement partiel ou filesystem corrompu

🔧 Solutions étape par étape

1

Diagnostic rapide

terminal
# Voir les derniers segfaults système
journalctl -k | grep segfault | tail -20
dmesg | grep segfault | tail -20

# Voir les core dumps disponibles
coredumpctl list
coredumpctl info

# Lancer avec strace pour voir l'appel système qui plante
strace -o /tmp/trace.txt ./mon-programme
tail -20 /tmp/trace.txt
2

Analyser avec GDB

terminal
# Activer les core dumps
ulimit -c unlimited

# Lancer le programme
./mon-programme
# → segmentation fault (core dumped)

# Analyser le core dump avec GDB
gdb ./mon-programme core
# Dans GDB :
(gdb) bt         # Backtrace — pile d'appels
(gdb) frame 0    # Aller au frame 0
(gdb) info locals  # Variables locales
(gdb) quit

# Analyser avec coredumpctl
coredumpctl gdb
3

Vérifier les librairies

terminal
# Voir les librairies requises par un binaire
ldd /usr/bin/mon-programme
ldd /chemin/mon-programme

# Si une lib est manquante (not found) :
apt search libmanquante
apt install libmanquante-dev

# Reconfigurer les librairies système
ldconfig

# Vérifier l'intégrité des paquets installés
dpkg --verify
debsums mon-paquet
4

Tester la RAM

terminal
# Tester la mémoire avec memtest (depuis GRUB)
# Redémarrer → sélectionner memtest86+

# Test rapide depuis Linux
apt install memtester
memtester 512M 3   # Tester 512MB, 3 fois

# Vérifier les erreurs ECC (si serveur)
edac-util -s 1
5

Vérifier le système de fichiers

terminal
# Vérifier l'intégrité des fichiers système
dpkg --verify 2>&1 | grep -v "^$"

# Réinstaller un paquet corrompu
apt install --reinstall mon-paquet

# Vérifier le FS (démonter d'abord !)
fsck /dev/sda1

# Chercher les fichiers corrompus
find /usr /lib -name "*.so*" -exec ldd {} 2>&1 \; | grep "not found"

🛡️ Comment éviter cette erreur

  • ✅ Toujours tester les mises à jour sur un environnement de test avant la production
  • ✅ Configurer les core dumps (ulimit -c unlimited) pour faciliter le diagnostic
  • ✅ Utiliser Valgrind (valgrind --leak-check=full ./programme) en développement
  • ✅ Surveiller les erreurs mémoire avec journalctl -k | grep -E 'MCE|ECC|error' sur les serveurs
Ajouter Les Fibrés à mes sources préférées
Retrouvez plus souvent nos guides dans vos résultats Google