Vous n'êtes pas identifié.
Salut à tous,
je suis en train d'installer mon petit serveur passerelle pour la maison, mais il est visiblement enrhumé : j'ai des «Erreur de segmentation» aléatoires.
1. Quelques détails sur la machine.
* Debian Etch (testing) à l'heure
* Bi-processeur : AMD Athlon XP
* Noyau linux-image-k7 (linux-image-2.6.18-4-k7)
2. Symptômes
* L'erreur est aléatoire et non-reproductible :
$ mkdir essai1 $ mkdir essai2 Erreur de segmentation $ mkdir essai2 $ mkdir essai3
* Arrive fréquemment avec Aptitude, apt et dpkg (avec lesquels j'essaie de tout réinstaller, ce qui pose d'autres problèmes de dépendances circulaires...)
* Visiblement, n'arrive qu'avec des applications lancées à la main, les démons ont l'air de tourner.
* De mémoire, n'arrivait pas avec le noyau 2.4 sans smp (donc avec un seul processeur reconnu et utilisé)
3. Médications entreprises
* J'ai essayé un memtest86+ pendant une ou deux heures : pas d'erreur visiblement détectée (mais quelle est la gueule de memtest86+ en cas d'erreur ?
* Réinstallation de plusieurs binaires (bash, python, ruby, aptitude, libc6, dpkg, ...)
4. Compréhension du problème
De ce que je comprends, la segmentation fault est une erreur provoquée dans un programme lors d'un accès non autorisé à une zone de mémoire :
* Ou mes binaires sont mal compilés (bizarre avec une distribution binaire quand même...)
* Ou mon matériel est mal branché ou défectueux, ce que memtest86+ n'a pas l'air de détecter...
Si quelqu'un a des explications et des solutions, je suis volontiers preneur !
@+, OdyX
Solution
* Une de mes deux barrettes de mémoire était morte.
* Il faut faire aller memtest86+ plus longtemps...
Hors ligne
Hello,
Ce comportement est parfois provoqué par un matériel (ram/cpu) défaillant en situation de surchauffe (et donc memtest86+ peut ne pas le détecter, suivant les cas...) est-ce que tu peux corréler les segfaults avec une haute charge système ?
Hors ligne
Salut,
Problème dans l'écriture de la table de partitions. Regarde du côté du système de fichier, peut-être.
A+.
Hors ligne
Salut,
merci pour vos explications... Malheureusement :
* Pour la proposition de BOFH
J'avais boinc-client installé, donc une utilisation des deux processeurs en permanence à 100% (ce qui est bien le but...). Mais en désinstallant boinc-client et en patientant le temps du refroidissement, j'ai toujours des erreurs... Cependant, j'ai lancé un petit script bash tout simple :
#!/bin/sh echo "Script de test pour ma mémoire..." i=0 while true do echo -n -e "$i\r" i=$(($i+1)) done
Et ça tourne encore. Donc je n'arrive pas à déclancher de segfault avec ça, mais réinstaller ca-certificates me le fait très fréquemment.
* Pour la proposition de jean@adimp.ch
3ème reboot avec fsck forcé au démarrage, aucun changement... Mes systèmes de fichiers (ReiserFS sur LVM et RAID5 (mdadm) sur SCSI) sont à priori propres.
D'autres idées ?
@+, OdyX
Hors ligne
Mh... j'ai de la peine à comprendre en quoi ton script sollicite la mémoire, justement ?
Question: quelle quantité de mémoire sur la box ? dans le mode par défaut, le test est vraiment très lent (connais pas les timings exacts, mais autour d'1h pour un Go, voire plus, sur la dernière machine que j'ai testée)
Hors ligne
Euh... Bonne question... L'idée est juste de solliciter le CPU... Mais mes compétences programmatiques sont visiblement limitées ;-). En effet, pas d'utilisation de la mémoire. Tu as un meilleur exemple ? Je tenterai avec une conversion avec mencoder ou un gag du style...
Pour la mémoire, je regarde en rentrant, mais je crois que c'est 1 Gio et je vais lancer memtest86+ pour la fin de l'après-midi...
@+, OdyX
Hors ligne
Salut,
Est-ce que tu obtient le message d'erreur avec d'autres instructions que mkdir?
A+.
Hors ligne
Salut,
Partir en debug avec gdb, pour cerner plus précisément la faute serait peut-être une solution.
root@artzh:# gdb mkdir GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test1 Starting program: /bin/mkdir test1 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program exited normally. (gdb) run test2 Starting program: /bin/mkdir test2 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program exited normally. (gdb) q root@artzh:# ls test* test1: test2:
A+.
Hors ligne
Oui... Je l'obtiens avec une foultitude de commandes différentes... Particulièrement avec tout ce qui est appellé par aptitude (grep, bash, dpkg, ...), mais c'est parce que c'est la seule commande que j'utilise...
Je penserai à gdb.
Par contre, ce qui est bizarre, c'est que je m'y connecte via ssh et que je n'ai jamais été déconnecté : le démon sshd ne segfaulte pas !?
++, OdyX
Hors ligne
Salut,
Est-ce que ce serait un problème d'accés à la mémoire protégée? Un programme n'arrive pas à aller repêcher les données dans la partie protégée? Et si tu changes tes barettes mémoires ( ce qui n'a aucun lien avec les questions précédentes ) ?
A+.
Dernière modification par jean@adimp.ch (14 Mar 2007 11:31:02)
Hors ligne
En fait, c'est peut-être bêtement un rootkit qui foire ? la box était vulnérable depuis l'extérieur ?
- chkrootkit, on sait jamais
- stop les services réseau, tcpdump, et vérifie si des commandes bateau d'accès au FS génèrent du traffic réseau ?
- si tu as une machine avec la même version de la distro, compare les tailles et empreintes md5 des binaires de base (ls, ps, netstat, ...)
- boot sur un livecd et regarde si ca continue a crasher
- boot sur un livecd, chroot dans ton ancien environnement et regarde si ca continue à crasher
Hors ligne
OK...
- chkrootkit fait lui-même des segfaults... Pas sur les mêmes tests à chaque fois... Mais en moyenne, il ne détecte rien (en moyenne, parce que le reste des tests sont insignifiants pour cause de segfault).
- deuxième question... Comment je voit s'il y a du trafic réseau ?
Nouveau script :
#!/bin/sh echo "Script de test pour ma mémoire..." i=0 while true do echo -n -e "Flip-flop dossier : _test$i\r" mkdir _test_$i rmdir _test_$i i=$(($i+1)) done
Celui-là est plus flagrant que mon dernier essai...
$ ./test_seg.sh Script de test pour ma mémoire... ./test_seg.sh: line 14: 23801 Erreur de segmentation mkdir _test_$i rmdir: _test_5: Aucun fichier ou répertoire de ce type mkdir: ne peut créer le répertoire `_test_28': Le fichier existe. ./test_seg.sh: line 14: 23865 Erreur de segmentation mkdir _test_$i rmdir: _test_37: Aucun fichier ou répertoire de ce type ./test_seg.sh: line 14: 23873 Erreur de segmentation mkdir _test_$i rmdir: _test_41: Aucun fichier ou répertoire de ce type Flip-flop dossier : _test_55
Bon... deux barrettes de mémoire : J'arrête la machine, j'en enlève une, je redémarre : c'est bon !
Conclusion : une barrette de mémoire foutue : memtest86+ pas assez long...
Mea culpa !
@+, OdyX et MERCI à BOFH et jean@adimp.ch
Hors ligne
N.B. J'ai laissé tourner mon script pendant un moment (je l'avais oublié...) : il a créé puis détrui 359'815'986 fois un dossier... presque 360 millions de fois, sans erreur, je crois que c'est bon.
Hors ligne
Pas d'occupation, mais je doute que ce soit fort agréable pour le disque dur si le cache n'a pas fait son boulot.. plein de toutes petites lectures/écritures frénétiques...
Hors ligne