El 10% de los fallos de Firefox se debe a defectos de hardware causados por bit flips

 (mas.to)
2 puntos por GN⁺ 2026-03-06 | 1 comentarios | Compartir por WhatsApp
  • El análisis de los reportes de fallos de Firefox mostró que los errores de hardware causados por bit flips representan una parte significativa del total de fallos
  • En la última semana, de unos 470 mil reportes de fallos, 25 mil fueron detectados como casos con posible bit flip
  • Se confirmó que, más que bugs de software, los defectos de hardware pueden explicar hasta un 10~15% de los fallos
  • La herramienta de prueba de memoria que se ejecuta después de un fallo revisa como máximo 1 GiB en menos de 3 segundos, pero aun así detecta muchos defectos reales
  • Este problema afecta a todos los dispositivos, como PC, smartphones, routers e impresoras, y deja en evidencia los límites de confiabilidad del hardware de consumo

Fallos de Firefox y detección de bit flips

  • Se diseñó un método para detectar el fenómeno de bit-flip en los reportes de fallos de Firefox, y luego se desplegó una herramienta de prueba de memoria que se ejecuta automáticamente tras un fallo en dispositivos de usuarios reales
    • Esta herramienta se ejecuta en el dispositivo del usuario justo después de que el navegador falla para revisar errores de memoria
  • El análisis de los datos recopilados confirmó que la heurística de detección de bit flips es válida y que muchos fallos ocurren en memoria defectuosa o hardware inestable

Resultados estadísticos

  • Durante la última semana se recibieron cerca de 470 mil reportes de fallos, que solo incluyen una parte del total de fallos (bajo un esquema de opt-in)
    • De ellos, unos 25 mil casos (aprox. 5%) fueron detectados como fallos con posible bit flip
    • La proporción real es una estimación conservadora, y podría ser más del doble en la práctica
  • Del total de fallos de Firefox, hasta un 10% se debe a defectos de hardware y, si se excluyen los fallos por agotamiento de recursos como falta de memoria, la cifra llega a alrededor del 15%
    • La cifra puede estar algo sesgada porque los usuarios con hardware defectuoso tienden a experimentar fallos con mayor frecuencia

Resultados de las pruebas de memoria

  • La herramienta de prueba de memoria ejecutada después del fallo revisa hasta 1 GiB de memoria en menos de 3 segundos, pero detecta muchos defectos reales de hardware
    • En uno de cada dos fallos estimados como bit flip se confirmó un defecto real
  • Aunque la prueba tiene un alcance limitado, muestra que la tasa real de errores es alta

Impacto en todo el hardware

  • Este problema afecta a todos los dispositivos electrónicos, no solo computadoras y smartphones, sino también routers e impresoras
    • También se reportaron muchos fallos en dispositivos como MacBook con ARM, donde la RAM está soldada dentro del paquete del CPU
    • Reemplazar la RAM de esos equipos es imposible sin equipo especializado y técnicos con experiencia

Debate en la comunidad e información adicional

  • Algunos usuarios compartieron casos de RAM defectuosa y experiencias con pruebas de memtest86, señalando la falta de control de calidad por parte de los fabricantes
  • Continuó la discusión sobre la necesidad de usar RAM con ECC, y se planteó que incluso SECDED ECC podría extender considerablemente la vida útil de los dispositivos de consumo
  • Se mencionó que existen estudios sobre errores de memoria en entornos de servidor, pero que es difícil compararlos directamente con dispositivos de consumo porque las condiciones son distintas
  • El análisis de datos confirmó una fuerte correlación entre el envejecimiento del dispositivo y la tasa de errores de memoria
  • Los bit flips pueden causar no solo fallos temporales, sino también pérdida permanente de datos, como corrupción del sistema de archivos, por lo que se destacó la importancia de los sistemas de archivos basados en checksums

Conclusión

  • Queda claro que una proporción significativa de los fallos de Firefox proviene de problemas de hardware y no de defectos de software
  • Se subraya la necesidad de detectar errores de memoria e incorporar ECC en dispositivos de consumo
  • Es un caso que muestra que asegurar la confiabilidad del hardware está directamente relacionado con mejorar la estabilidad del software

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-03-06
Opiniones en Hacker News

  • Ya lo había comentado antes en HN, pero Mike O’Brien (el creador de battle.net), que fue colega mío en la época de ArenaNet, creó hacia 2004 un sistema de detección de bit flips para Guild Wars
    En cada frame (aprox. 60 FPS), asignaba memoria aleatoria, ejecutaba operaciones matemáticas y comparaba el resultado con una tabla de valores de referencia; alrededor de 1 de cada 1000 equipos fallaba
    La causa solía ser CPUs con overclock, estados de espera de memoria mal configurados, falta de energía, mala refrigeración, etc., y como el juego renderizaba mucho terreno exterior, las computadoras tendían a sobrecalentarse
    Más adelante se descubrió que también podían influir problemas de calidad en componentes baratos de Dell o incluso ataques RowHammer
    Yo escribí código para que, si la prueba fallaba, se abriera el navegador y mostrara una página diciendo “limpia los ventiladores de tu computadora”

    • Como desarrollador móvil de YouTube, al ver los reportes de crashes del código que llevaba, algunos simplemente no tenían ningún sentido
      En esos casos, casi siempre pensé que se debían a bit flips aleatorios o hardware defectuoso
    • No entiendo por qué la memoria ECC todavía no es el estándar
      Es un poco más cara, pero resuelve casi todos estos problemas. Algunas motherboards de consumo ya soportan ECC
    • Guild Wars 1 fue el juego de mi infancia
      A mis padres les gustaba porque no tenía suscripción mensual, y el sistema de builds de 8 habilidades era realmente genial
      Si sale una tercera entrega, ojalá dé más libertad para expresar builds
    • Ya había leído esta historia antes en el blog Code of Honor
    • Gracias a una motherboard ASRock pude usar memoria ECC con un Threadripper 1950x
      Durante pruebas de overclock, ECC permitió detectar errores sutiles, y desde entonces nunca más volví a confiar en overclock sin ECC
      DDR5 en particular es difícil de estabilizar y sensible al calor, así que veo imposible hacer overclock sin ECC

  • La memoria ECC debió haberse vuelto estándar desde que se superó 1 GB
    Hoy en día me molesta que la memoria con LED RGB inútiles sea barata y la ECC sea cara

    • Más que la ECC en sí, lo difícil es conseguir CPU y motherboard compatibles
      AMD al menos da “soporte parcial” a ECC en CPUs de consumo, pero Intel solo lo permite en la gama workstation
    • DDR5 trae por defecto una función integrada de corrección de errores
      Pero no está claro que sea más confiable que DDR4 sin ECC
    • Creo que la raíz del problema es la política de Intel
    • Casi nunca he visto memoria ECC en laptops
      Si fuera posible, me gustaría usar una laptop con ECC
    • ECC tradicionalmente ha sido más lenta y compleja, y no elimina por completo el problema
      Pero en entornos de servidor, con energía y temperatura estables, previene el 99% de los errores

  • El equipo de Go introdujo un sistema de reportes de crashes basado en telemetría
    Con runtime.SetCrashOutput recopilaron stacks de crashes de goroutines y lograron detectar cientos de bugs
    Pero algunos reportes eran imposibles de explicar, como si hubiera corrupción de memoria o mal funcionamiento del CPU
    Como la mayoría de los usuarios de laptop usan memoria sin ECC, concluyeron que probablemente se trataba de fallas de hardware

    • Los bit flips también afectan al propio código, así que hasta los resultados de telemetría pueden ser difíciles de confiar
    • Si se agregara información de temperatura del CPU a los reportes, quizá se podría filtrar hardware que se sobrecalienta
    • En apps de iOS también he visto de vez en cuando crashes incomprensibles, y podrían haber sido bit flips en iPads viejos
    • Yo también estoy intentando convencer a mi jefe de implementar telemetría centrada en crashes en producción

  • Yo también quiero compartir este caso de bit flips del blog de JuliaLang

  • La afirmación de que “el 10% de los crashes de Firefox se deben a fallas de hardware” suena demasiado atrevida
    En navegadores basados en Chromium no parece haber crashes con tanta frecuencia

    • La intuición podría estar equivocada
      Quizá Chrome es más estable porque maneja mejor el otro 90% de los bugs de software
      De hecho, también podría significar que la mayoría de los crashes de Firefox son problemas de software
    • Que el 10% de los crashes sea así no significa que aplique igual a todos los usuarios
    • Mi Firefox casi nunca se cae. Puedo dejarlo abierto por semanas con decenas de pestañas sin problemas
    • Los usuarios con mal hardware podrían estar enviando muchos más crashes adicionales
    • Hace meses que no veo un crash ni en Firefox ni en Chrome. Recomiendo hacer stress test al hardware

  • Vi un texto que decía “estamos seguros de que la causa son bit flips”, pero faltó explicar cómo lo detectaron

    • Probablemente usan un método como memtest86: escribir patrones en memoria, leerlos de vuelta y compararlos
      El memory_test.rs del código fuente de Mozilla parece cumplir esa función
    • De hecho, se menciona explícitamente que “ejecutan una prueba de memoria en la PC del usuario después de un crash del navegador”
    • Al final, parece que más que detectar bit flips directamente, observaron crashes provocados por memoria inestable
    • Un caso común es el segfault causado por un error de un solo bit, como cuando un puntero tiene un bit incorrecto

  • Compré una PC nueva y al hacer overclock de la RAM a 5800 MHz, Fedora empezó a colgarse raro y las apps no abrían
    Corrí memtest y en dos minutos empezaron a salir errores en rojo por todos lados; bajé la velocidad a 5200 y quedó estable
    Qué sincronía tan precisa encontrar un post así justo en la portada de HN

  • Me sorprende que la tasa de crashes de Firefox sea más alta de lo que pensaba
    Llevo años teniendo crashes al cerrar, y siempre envío el reporte cada vez
    Todas mis extensiones son WebExtension, pero las causas que aparecen son variadas
    Firefox maneja bien múltiples ventanas y pestañas, pero todavía necesita mejorar en estabilidad

    • Los crashes al cerrar también podrían ser consecuencia de corrupción de memoria
      Como durante el cierre se libera mucha memoria, es más fácil que un bit flip salga a la luz
      Para comprobar la causa, convendría hacer una prueba de memoria
    • Si es posible, piden compartir el enlace del reporte en about:crashes

  • Me alegra ver que alguien realmente está recopilando este tipo de datos
    Creo que el problema de la memoria defectuosa es uno de los temas más subestimados en computación
    Estaría bien tener un resumen corto en formato de nota técnica