2 pontos por GN⁺ 2026-03-06 | 1 comentários | Compartilhar no WhatsApp
  • A análise dos relatórios de falha do Firefox mostrou que erros de hardware causados por bit flips representam uma parte significativa de todas as falhas
  • Na última semana, entre cerca de 470 mil relatórios de falha, 25 mil casos foram detectados como possíveis ocorrências de bit flip
  • Foi confirmado que, em vez de bugs de software, defeitos de hardware podem ser a causa de até 10% a 15% das falhas
  • A ferramenta de teste de memória executada após a falha verifica em até 3 segundos no máximo 1 GiB, mas ainda assim encontra muitos defeitos reais
  • Esses problemas afetam todos os dispositivos, como PCs, smartphones, roteadores e impressoras, revelando os limites da confiabilidade do hardware de consumo

Falhas do Firefox e detecção de bit flips

  • Foi projetado um método para detectar o fenômeno de bit flip nos relatórios de falha do Firefox, e depois foi distribuída uma ferramenta de teste de memória executada automaticamente em dispositivos reais de usuários após uma falha
    • Essa ferramenta é executada no dispositivo do usuário logo após a falha do navegador para verificar erros de memória
  • A análise dos dados coletados confirmou que a heurística de detecção de bit flips é válida, e que muitas falhas ocorrem em memória defeituosa ou hardware instável

Resultados estatísticos

  • Na última semana, foram recebidos cerca de 470 mil relatórios de falha, incluindo apenas uma parte do total de falhas (modelo opt-in)
    • Desses, cerca de 25 mil casos (aproximadamente 5%) foram detectados como falhas com possibilidade de bit flip
    • Essa proporção é uma estimativa conservadora, e o valor real pode ser mais que o dobro
  • Entre todas as falhas do Firefox, até 10% são causadas por defeitos de hardware e, excluindo falhas por esgotamento de recursos como falta de memória, o número chega a cerca de 15%
    • Os números podem estar um pouco distorcidos, já que usuários com hardware defeituoso tendem a enfrentar falhas com mais frequência

Resultados do teste de memória

  • A ferramenta de teste de memória executada após a falha verifica até 1 GiB de memória em menos de 3 segundos, mas detecta muitos defeitos reais de hardware
    • Em um de cada dois casos de falha presumidos como bit flip, um defeito real foi confirmado
  • Apesar do escopo limitado do teste, ele mostra que a taxa real de erro é alta

Impacto em todo o hardware

  • Esses problemas afetam não apenas computadores e smartphones, mas todos os dispositivos eletrônicos, como roteadores e impressoras
    • Muitas falhas também foram relatadas em dispositivos como MacBook com ARM, em que a RAM é soldada ao pacote da CPU
    • Nesses dispositivos, substituir a RAM é impossível sem equipamento especializado e um técnico experiente

Discussão da comunidade e informações adicionais

  • Alguns usuários compartilharam casos de RAM defeituosa e experiências com o teste memtest86, apontando a ausência de controle de qualidade por parte dos fabricantes
  • Houve discussão sobre a necessidade de ECC RAM, com a opinião de que mesmo SECDED ECC já poderia aumentar bastante a vida útil dos dispositivos de consumo
  • Embora existam estudos sobre erros de memória em ambientes de servidor, foi mencionado que as condições são diferentes das dos dispositivos de consumo, dificultando comparações diretas
  • A análise dos dados confirmou uma forte correlação entre o envelhecimento do dispositivo e a taxa de ocorrência de erros de memória
  • Um bit flip pode causar não apenas uma falha simples, mas também perda permanente de dados, como corrupção do sistema de arquivos, destacando a importância de sistemas de arquivos baseados em checksum para prevenção

Conclusão

  • Fica claro que uma proporção significativa das falhas do Firefox se origina de problemas de hardware, e não de defeitos de software
  • Ganha destaque a necessidade de detecção de erros de memória e adoção de ECC em dispositivos de consumo
  • Este é um caso que mostra que garantir a confiabilidade do hardware está diretamente ligado à melhoria da estabilidade do software

1 comentários

 
GN⁺ 2026-03-06
Comentários do Hacker News
  • Já comentei isso no HN antes, mas um ex-colega da época da ArenaNet, Mike O’Brien (criador do battle.net), criou por volta de 2004 um sistema de detecção de bit flip para Guild Wars
    A cada frame (cerca de 60 FPS), ele alocava memória aleatória, executava operações matemáticas e comparava o resultado com uma tabela de valores de referência; cerca de 1 em cada 1000 máquinas falhava
    As causas eram, em sua maioria, CPU com overclock, timings de memória incorretos, alimentação insuficiente, refrigeração ruim etc., e o jogo renderizava muito terreno externo, então os computadores frequentemente superaqueciam
    Mais tarde, descobriram que problemas de qualidade em componentes baratos da Dell ou até ataques RowHammer também poderiam ser a causa
    Eu escrevi um código que, quando o teste falhava, abria o navegador e mostrava uma página dizendo para “limpar as ventoinhas do computador”

    • Como desenvolvedor mobile do YouTube, quando vejo os relatórios de crash do código pelo qual sou responsável, alguns simplesmente não fazem sentido
      Nesses casos, eu geralmente suspeitava de bit flips aleatórios ou hardware defeituoso
    • Não entendo por que memória ECC ainda não é padrão
      Ela é um pouco mais cara, mas resolve quase todos esses problemas. Algumas placas-mãe de consumo já oferecem suporte a ECC
    • Guild Wars 1 foi o jogo da minha infância
      Meus pais gostavam porque não havia mensalidade, e o sistema de build com 8 skills era realmente genial
      Se sair um 3º jogo, eu gostaria que houvesse ainda mais liberdade de expressão nas builds
    • Li essa história tempos atrás no blog Code of Honor
    • Graças a uma placa-mãe ASRock, consegui usar memória ECC em um Threadripper 1950x
      Durante testes de overclock, o ECC detectou erros sutis, e desde então nunca mais consegui confiar em overclock sem ECC
      O DDR5, em especial, é difícil de estabilizar e sensível ao calor, então considero impossível fazer overclock sem ECC
  • Memória ECC deveria ter virado padrão quando passamos de 1 GB
    Hoje, memória com LED RGB inútil é barata, enquanto ECC é cara, e isso me incomoda

    • Mais difícil do que o ECC em si é encontrar CPU e placa-mãe compatíveis
      A AMD ao menos oferece “suporte parcial” a ECC em CPUs de consumo, mas a Intel só permite isso na linha workstation
    • O DDR5 já vem com correção de erro embutida por padrão
      Mas não está claro se ele é mais confiável que DDR4 sem ECC
    • Acho que a causa fundamental desse problema é a política da Intel
    • Quase nunca vi memória ECC em notebook
      Se fosse possível, eu gostaria de usar um notebook com ECC
    • ECC tradicionalmente é mais lento e mais complexo, e não elimina completamente os problemas
      Mas, em ambientes de servidor com condições estáveis de energia e temperatura, ele previne 99% dos erros
  • A equipe do Go introduziu um sistema de relatórios de crash baseado em telemetria
    Com runtime.SetCrashOutput, eles coletaram stacks de crash de goroutines e encontraram centenas de bugs
    Mas alguns relatórios eram casos que não davam para explicar, como corrupção de memória ou mau funcionamento da CPU
    Como a maioria dos usuários de notebook usa memória sem ECC, concluíram que a possibilidade mais forte era defeito de hardware

    • Bit flips também afetam o próprio código, então até os resultados da telemetria ficam difíceis de confiar
    • Se adicionassem informações de temperatura da CPU aos relatórios, talvez fosse possível filtrar hardware superaquecido
    • Também já vi crashes inexplicáveis em apps iOS, e talvez fossem bit flips em iPads antigos
    • Eu também estou tentando convencer meu chefe a introduzir telemetria centrada em crashes em produção
  • Também quero compartilhar o caso de bit flip no blog da JuliaLang

  • A afirmação de que “10% dos crashes do Firefox são causados por defeitos de hardware” parece ousada demais
    Em navegadores baseados em Chromium, não vejo crashes com tanta frequência

    • Minha intuição pode estar errada
      Talvez o Chrome seja mais estável porque lida melhor com os outros 90% de bugs de software
      Na verdade, isso pode até significar que a maior parte dos crashes do Firefox vem de problemas de software
    • O fato de 10% dos crashes serem assim não significa que isso se aplique igualmente a todos os usuários
    • Meu Firefox quase nunca cai. Posso deixar dezenas de abas abertas por semanas sem problema
    • Usuários com hardware ruim podem acabar enviando muito mais crashes adicionais
    • Faz meses que não vejo Firefox ou Chrome crasharem. Eu recomendaria fazer um stress test no hardware
  • Vi um texto dizendo “temos certeza de que a causa é bit flip”, mas faltou explicar como isso foi detectado

    • Provavelmente é algo como o memtest86: escreve padrões na memória, lê de volta e compara
      O memory_test.rs no código-fonte do Mozilla também parece fazer esse papel
    • De fato, há menção a “executar um teste de memória no PC do usuário após o crash do navegador”
    • No fim, parece que eles não detectaram bit flips diretamente, mas observaram crashes causados por memória instável
    • Um caso comum é o de segfault causado por erro de um único bit, como quando apenas um bit de um ponteiro está incorreto
  • Comprei um PC novo e fiz overclock da RAM para 5800 MHz, e o Fedora começou a travar de forma estranha e os apps não abriam
    Rodei memtest e, em 2 minutos, apareceu uma enxurrada de erros vermelhos; baixei a frequência para 5200 e tudo ficou estável
    É um timing perfeito ver um post desses na primeira página do HN

  • Fiquei surpreso que a taxa de crash do Firefox seja mais alta do que eu imaginava
    Há anos continuo tendo crash ao encerrar e envio o relatório toda vez
    Todas as extensões são WebExtension, mas as causas parecem variar
    O Firefox lida bem com múltiplas janelas e abas, mas ainda precisa melhorar em estabilidade

    • Crash ao encerrar também pode ser resultado de corrupção de memória
      Como o processo de encerramento libera muita memória, bit flips podem ficar mais aparentes nessa etapa
      Para confirmar a causa, pode valer a pena rodar um teste de memória
    • Se possível, pedem para compartilhar o link do relatório em about:crashes
  • Fico feliz em ver que alguém está realmente coletando esse tipo de dado
    Acho que o problema de memória defeituosa é uma das questões mais subestimadas da computação
    Seria bom ter um resumo curto em formato de white paper