10 % des crashs de Firefox seraient dus à des défauts matériels provoquant des bit flips

• L’analyse des rapports de plantage de Firefox montre que les erreurs matérielles dues à des bit flips représentent une part importante de l’ensemble des crashs
• Sur la dernière semaine, environ 25 000 rapports sur 470 000 ont été détectés comme des cas potentiellement liés à des bit flips
• Il a été confirmé que des défaillances matérielles, et non des bugs logiciels, peuvent être à l’origine de 10 à 15 % des crashs
• L’outil de test mémoire exécuté après un crash n’inspecte qu’un maximum de 1 GiB en moins de 3 secondes, mais détecte malgré tout de nombreux défauts réels
• Ces problèmes touchent tous les appareils, y compris les PC, smartphones, routeurs et imprimantes, et mettent en lumière les limites de la fiabilité du matériel grand public

---

Crashs de Firefox et détection des bit flips

• Une méthode a été conçue pour détecter les phénomènes de bit flip dans les rapports de plantage de Firefox, puis un outil de test mémoire lancé automatiquement après un crash a été déployé sur les appareils des utilisateurs
  • Cet outil s’exécute sur l’appareil de l’utilisateur immédiatement après le crash du navigateur afin de vérifier la présence d’erreurs mémoire
• L’analyse des données collectées a confirmé que l’heuristique de détection des bit flips est efficace, et qu’un grand nombre de crashs proviennent de mémoire défectueuse ou de matériel instable

Résultats statistiques

• Environ 470 000 rapports de plantage ont été reçus au cours de la dernière semaine, ce qui ne couvre qu’une partie des crashs totaux (sur la base de l’opt-in)
  • Parmi eux, environ 25 000 cas (soit 5 %) ont été détectés comme des crashs potentiellement liés à des bit flips
  • Ce ratio est une estimation prudente, et le taux réel pourrait être plus de deux fois supérieur
• Sur l’ensemble des crashs de Firefox, jusqu’à 10 % seraient dus à des défauts matériels, et environ 15 % si l’on exclut les crashs liés à l’épuisement des ressources, comme le manque de mémoire
  • Ces chiffres peuvent être légèrement biaisés, car les utilisateurs disposant d’un matériel défectueux ont tendance à subir des crashs plus fréquents

Résultats des tests mémoire

• L’outil de test mémoire exécuté après le crash inspecte jusqu’à 1 GiB de mémoire en moins de 3 secondes, tout en détectant de nombreux défauts matériels réels
  • Dans un crash sur deux présumé causé par un bit flip, un défaut réel a été confirmé
• Malgré sa portée limitée, le test montre que le taux réel d’erreurs est élevé

Impact sur l’ensemble du matériel

• Ces problèmes affectent non seulement les ordinateurs et les smartphones, mais aussi les routeurs, imprimantes et autres appareils électroniques
  • De nombreux crashs ont également été signalés sur des appareils comme les MacBook ARM, où la RAM est soudée dans le package CPU
  • Sur ces appareils, le remplacement de la RAM est impossible sans équipement spécialisé et sans technicien expérimenté

Discussions de la communauté et informations complémentaires

• Certains utilisateurs ont partagé des cas de RAM défectueuse et leurs expériences avec les tests memtest86, en pointant l’absence de contrôle qualité chez certains fabricants
• La nécessité de la RAM ECC a également été discutée, avec l’idée que la SECDED ECC à elle seule pourrait considérablement prolonger la durée de vie des appareils grand public
• Il est mentionné qu’il existe des études sur les erreurs mémoire en environnement serveur, mais que les conditions diffèrent de celles du matériel grand public, ce qui rend les comparaisons directes difficiles
• L’analyse des données a confirmé une forte corrélation entre le vieillissement des appareils et le taux d’erreurs mémoire
• Les bit flips peuvent provoquer non seulement des crashs, mais aussi des pertes de données permanentes, comme la corruption du système de fichiers ; d’où l’importance soulignée des systèmes de fichiers à base de checksum pour s’en prémunir

Conclusion

• Il apparaît clairement qu’une part importante des crashs de Firefox provient de problèmes matériels plutôt que de défauts logiciels
• La nécessité de détecter les erreurs mémoire et d’adopter l’ECC sur les appareils grand public est mise en avant
• C’est un exemple qui montre que la fiabilité matérielle est directement liée à l’amélioration de la stabilité logicielle

[GN⁺]

Avis Hacker News

• J’en avais déjà parlé sur HN, mais un ancien collègue de l’époque ArenaNet, Mike O’Brien (le créateur de battle.net), avait mis en place vers 2004 un système de détection des bit flips dans Guild Wars
  À chaque frame (environ 60 FPS), il allouait de la mémoire aléatoirement, lançait des opérations mathématiques, puis comparait le résultat à une table de valeurs de référence, et environ 1 machine sur 1000 échouait
  Les causes étaient le plus souvent des CPU overclockés, des timings mémoire incorrects, une alimentation insuffisante ou un refroidissement défaillant, et comme le jeu rendait beaucoup de terrain en extérieur, les ordinateurs surchauffaient souvent
  Plus tard, on a aussi compris que des problèmes de qualité sur des composants bas de gamme de Dell ou encore l’attaque RowHammer pouvaient en être la cause
  J’avais écrit du code qui, en cas d’échec du test, ouvrait le navigateur pour afficher une page disant de « nettoyer les ventilateurs de l’ordinateur »

  • En tant que développeur mobile chez YouTube, quand je regarde les rapports de crash du code dont je m’occupe, certains n’ont absolument aucun sens
    Dans ces cas-là, j’ai souvent pensé qu’il s’agissait de bit flips aléatoires ou de matériel défectueux
  • Je ne comprends pas pourquoi la mémoire ECC n’est toujours pas la norme
    C’est un peu plus cher, mais cela résout presque entièrement ce genre de problèmes. Certaines cartes mères grand public prennent déjà l’ECC en charge
  • Guild Wars 1 était le jeu de mon enfance
    Mes parents l’aimaient parce qu’il n’y avait pas d’abonnement mensuel, et le système de build à 8 compétences était vraiment génial
    Si un troisième opus sort un jour, j’aimerais qu’il offre encore plus de liberté dans l’expression des builds
  • J’avais déjà lu cette histoire sur le blog Code of Honor
  • Grâce à une carte mère ASRock, j’ai pu utiliser de la mémoire ECC avec un Threadripper 1950x
    Pendant des tests d’overclocking, l’ECC m’a permis de détecter des erreurs subtiles, et depuis, je ne fais plus jamais confiance à un overclocking sans ECC
    La DDR5 est particulièrement difficile à stabiliser et sensible à la chaleur, donc à mes yeux l’overclocking sans ECC y est impossible

• La mémoire ECC aurait dû devenir la norme dès qu’on a dépassé 1 Go
  Aujourd’hui, la RAM RGB à LED inutile est bon marché, tandis que l’ECC reste cher, et ça m’agace

  • Plus que l’ECC lui-même, le plus difficile est de trouver un CPU et une carte mère compatibles
    AMD propose au moins une « prise en charge partielle » de l’ECC sur ses CPU grand public, alors qu’Intel le réserve aux machines de type workstation
  • La DDR5 intègre par défaut une fonction de correction d’erreurs embarquée
    Mais on ne sait pas vraiment si elle est plus fiable que de la DDR4 sans ECC
  • Je pense que la cause profonde de ce problème, c’est la politique d’Intel
  • Je n’ai quasiment jamais vu de mémoire ECC dans un portable
    Si c’était possible, j’aimerais utiliser un ordinateur portable équipé d’ECC
  • L’ECC a traditionnellement été plus lent et plus complexe, et n’élimine pas totalement les problèmes
    Mais dans un environnement serveur avec une alimentation stable et des températures maîtrisées, cela évite 99 % des erreurs

• L’équipe Go a introduit un système de rapports de crash basé sur la télémétrie
  Avec runtime.SetCrashOutput, ils ont collecté les stacks de crash des goroutines et corrigé des centaines de bugs
  Mais certains rapports restaient inexplicables, comme en cas de corruption mémoire ou de dysfonctionnement CPU
  Comme la plupart des utilisateurs de portables utilisent de la mémoire sans ECC, ils ont estimé qu’un défaut matériel était probable

  • Les bit flips peuvent aussi affecter le code lui-même, donc même les résultats de la télémétrie sont difficiles à croire
  • Ajouter la température du CPU dans les rapports permettrait peut-être d’écarter le matériel en surchauffe
  • J’ai aussi parfois vu des crashs incompréhensibles sur des apps iOS, et cela pourrait venir de bit flips sur de vieux iPad
  • J’essaie moi aussi de convaincre mon manager d’adopter une télémétrie centrée sur les crashs en production

• J’aimerais aussi partager le cas de bit flip raconté sur le blog JuliaLang

• L’affirmation selon laquelle « 10 % des crashs de Firefox sont dus à des défauts matériels » me paraît assez audacieuse
  Les navigateurs basés sur Chromium ne crashent pas aussi souvent

  • Mon intuition peut être fausse
    Si Chrome est plus stable, c’est peut-être parce qu’il gère mieux les 90 % restants de bugs logiciels
    Cela pourrait au contraire vouloir dire que la plupart des crashs de Firefox relèvent de problèmes logiciels
  • Même si 10 % des crashs sont de ce type, cela ne s’applique pas forcément de la même manière à tous les utilisateurs
  • Mon Firefox ne plante presque jamais. Je peux laisser des dizaines d’onglets ouverts pendant des semaines sans problème
  • Les utilisateurs ayant du mauvais matériel ont peut-être tendance à envoyer davantage de crashs supplémentaires
  • Je n’ai pas vu Firefox ou Chrome planter depuis des mois. Je recommande de stress tester le matériel

• J’ai lu un message disant « nous sommes certains que la cause est un bit flip », mais il manque des explications sur la méthode de détection

  • C’est probablement un mécanisme semblable à memtest86, qui écrit des motifs en mémoire, puis les relit pour les comparer
    Le fichier memory_test.rs dans le code source de Mozilla semble jouer ce rôle
  • Il est effectivement mentionné qu’« un test mémoire est exécuté après le crash du navigateur sur le PC de l’utilisateur »
  • Au final, ils n’ont sans doute pas détecté directement les bit flips, mais plutôt observé des crashs dus à une mémoire instable
  • Un cas fréquent est le segfault provoqué par une erreur sur un seul bit, par exemple lorsqu’un seul bit d’un pointeur est incorrect

• J’ai acheté un nouveau PC et overclocké la RAM à 5800 MHz, puis Fedora a commencé à se figer bizarrement et les applications ne se lançaient plus
  En lançant memtest, j’ai vu défiler des erreurs en rouge au bout de deux minutes seulement, et tout est redevenu stable en redescendant à 5200
  Le timing est parfait de tomber sur un tel post en première page de HN

• Je suis surpris que le taux de crash de Firefox soit si élevé
  Depuis des années, j’ai régulièrement des crashs à la fermeture, et j’envoie un rapport à chaque fois
  Toutes mes extensions sont des WebExtensions, mais les causes indiquées semblent variées
  Firefox gère bien les multiples fenêtres et onglets, mais sa stabilité a encore besoin de progresser

  • Les crashs à la fermeture peuvent être la conséquence d’une corruption mémoire
    Comme beaucoup de mémoire est libérée au moment de la fermeture, les bit flips peuvent plus facilement se révéler
    Pour en avoir le cœur net, il vaudrait mieux faire un test mémoire
  • Si possible, quelqu’un demande de partager le lien du rapport dans about:crashes

• C’est appréciable de voir que quelqu’un collecte réellement ce type de données
  Je pense que le problème de mémoire défectueuse est l’un des sujets les plus sous-estimés de l’informatique
  J’aimerais bien voir une courte synthèse sous forme de note technique