web-dev-qa-db-fra.com

Mozilla (Thunderbird et / ou firefox) plante, entraînant la chute de chrome

Symptômes: Firefox et Thunderbird se bloquent de manière intermittente, généralement suivis de chrome.

Une fois que la panne s'est produite, le redémarrage entraînera une nouvelle panne presque immédiatement, jusqu'au redémarrage du système.

J'ai remplacé chaque pièce de matériel, fait une réinstallation complète deux fois. Ce problème ne se produit que sur l'un de mes systèmes (malheureusement, mon principal). J'ai d'autres systèmes Ubuntu qui fonctionnent bien.

Système d'exploitation:

  • Ubuntu 16.04
  • mais cela s'est produit aussi sous 15.10 (mais pas 15.04, IIRC)

Matériel:

  • AMD FX 9370 (8 coeurs)
  • RAM: 32 Go
  • Disque système: Crucial CT256MX (256gb)
  • disque de données: Seagate ST2000dx (2 To)
  • Graphiques: AMD FirePro W4100

Dépannage jusqu'à présent:

J'ai vérifié les erreurs habituelles (noyau, syslog, auth, etc.) dans/var/logs, mais je n'ai rien trouvé qui ressemble à une arme à feu fumante.

Toute aide appréciée.

firefoxgoogle-chromethunderbirdcrash
4
Leon Adato

Après des semaines de tests, de journalisation, d'analyse et même d'utilisation d'une version bêta de SolarWinds NPM et SAM, le problème semble concerner du matériel à problèmes multiples.

J'ai supprimé tous les plugins de FF et j'ai constaté que je pouvais fonctionner plus longtemps, mais que j'avais toujours des plantages toutes les 24 à 48 heures.

Bizarrement, lorsque j'ai exécuté deux machines virtuelles VirtualBox, j'ai découvert que je pouvais rester opérationnel 48 à 72 heures avant qu'un redémarrage ne soit nécessaire.

Mais les problèmes sont restés et j'ai décidé de revenir (vérifier) ​​le matériel. Ce que j'ai trouvé était:

1) Le SSD principal (lecteur de démarrage/système d'exploitation) avait une erreur de contrôleur

2) 1 des 4 bâtons de RAM portait des erreurs massives. Je devais exécuter MemTest86 sur chaque tick individuel (éteindre l'ordinateur, retirer tout, sauf un stick, démarrer sur un CD, lancer MemTest86, répéter le rinçage du lavage).

Changer le disque dur et enlever ce mauvais bâton de RAM m'a permis de continuer à fonctionner 4 jours sans aucun problème. Le remplacement RAM est imminent (je remercie Crucial pour sa garantie à vie et son processus de RMA sans tracas).

2
Leon Adato

Avez-vous essayé de regarder la santé du disque? Il existe peut-être un utilitaire plus courant, mais smartctl devrait faire l'affaire (en tant que root):

smartctl -a /dev/sda | more
1
Steven Klassen

Vous avez généré beaucoup de données et nous n’en avons pas tiré beaucoup d’informations. Vous avez probablement passé plus de temps que moi à googler les choses qui semblaient plus effrayantes dans dmesg et vous avez découvert que personne ne remarquait rien. Si vous êtes toujours disposé à persévérer, voici quelque chose d'un peu moins de botte de foin.

Hypothèse: S'il y a un problème matériel, il doit se manifester chaque fois avec le même ensemble d'appels d'API du noyau ou de la libc. c'est à dire.:

  • Un disque défectueux ou un contrôleur de disque produira constamment des traces de pile se terminant par open (), access (), read (), write (), etc.
  • Une mauvaise mémoire échouera généralement sur malloc ()/free () (mais cela pourrait devenir compliqué).
  • Un mauvais processeur se comportera de manière erratique
  • Un mauvais pilote vidéo produira une sorte de trace de pile inconnue, mais espérons-le, suffisamment intéressant pour attirer l'attention d'un développeur du noyau plus intelligent que nous.
  • Du côté logiciel, mozilla chrome et Thunderbird produisant des traces de pile traversant les mêmes bibliothèques de terrains utilisateur indiquent qu’elles se trouvent peut-être dans cette bibliothèque.

Expérience: collecte automatique des traces de pile . La réponse acceptée fait une supercherie Gdb. Cependant, il semble que libsegfault (ou si vous voulez collecter plus d’informations celui-ci) sera le meilleur "montrez-moi le segfault"

0
Justin Dearing