Mozilla (thunderbird an / ou firefox) travar, trazendo o cromo para baixo

Question

Sintomas : O Firefox e o Thunderbird travam intermitentemente, geralmente seguidos por chrome.

Quando a falha ocorrer, a reinicialização resultará em outra falha quase que imediatamente, até que o sistema seja reinicializado.

Eu substitui cada peça de hardware, fiz uma reinstalação completa duas vezes. Este problema ocorre apenas em um dos meus sistemas (infelizmente, meu principal). Eu tenho outros sistemas Ubuntu que estão funcionando bem.

Sistema operacional:

• Ubuntu 16.04
• mas isso também ocorreu em 15.10 (mas não em 15.04, IIRC)

Hardware:

• AMD FX 9370 (8 core)
• RAM: 32 GB
• Disco do sistema: Crucial CT256MX (256gb)
• disco de dados: Seagate ST2000dx (2Tb)
• Gráficos: AMD FirePro W4100

Resolução de problemas até agora:

Eu verifiquei os suspeitos usuais (kernel, syslog, auth, etc) em / var / logs em busca de erros, mas não encontrei nada que parecesse uma arma fumegante.

Qualquer ajuda apreciada.

    

Answer 1

Após semanas de testes, registro, análise e até mesmo o uso de uma versão beta do SolarWinds NPM e do SAM, o problema parece ser um hardware de vários problemas.

Eu removi todos os plug-ins do FF e descobri que era possível correr mais, mas ainda travava a cada 24 a 48 horas.

Estranhamente, quando eu executei duas VMs do VirtualBox, descobri que podia ficar ativo por 48 a 72 horas antes de ser necessário reinicializar.

Mas os problemas permaneceram e eu decidi voltar e checar o hardware (de novo). O que eu encontrei foi:

1) O SSD principal (unidade de inicialização / OS) tinha um erro de controlador

2) 1 das 4 varas de RAM teve erros maciços nele. Eu tive que executar o MemTest86 em cada tique individual (desligue o PC, remova todos, mas 1 stick, inicie o CD, execute o MemTest86, lave a repetição da lavagem).

Alterar o disco rígido e removê-lo permitiu que eu continuasse funcionando por 4 dias e sem sinais de problemas. A RAM de substituição está a caminho (agradeço à Crucial por sua garantia vitalícia e processo RMA sem complicações).

    

Answer 2

Já tentou ver a saúde do disco? Pode haver um utilitário mais atual, mas o smartctl deve fazer o truque (como root):

smartctl -a /dev/sda | more

    

Answer 3

Você gerou muitos dados e não obtemos muitas informações. Você provavelmente passou mais tempo pesquisando as coisas mais assustadoras no dmesg do que eu e descobriu que ninguém notou nada. Se você ainda está disposto a perseverar, aqui está algo um pouco menos palheiro.

Hipótese: Se houver um problema de hardware, ele deve se manifestar com o mesmo conjunto de chamadas de API do kernel ou libc sempre. ou seja:

• Um disco defeituoso ou um controlador de disco produzirá constantemente rastreamentos de pilha que terminem com open (), access (), read (), write () etc.
• A memória ruim geralmente falha em malloc () / free () (mas isso pode ficar complicado).
• CPU ruim se comportará de forma irregular
• O driver de vídeo ruim produzirá algum tipo de rastreamento de pilha desconhecido, mas esperamos que algo seja interessante o suficiente para chamar a atenção de um desenvolvedor do kernel mais inteligente do que nós
• No lado do software, o mozilla chrome e o thunderbird que produzem rastreamentos de pilha passando pelas mesmas bibliotecas de terreno do usuário indicam o que pode estar nessa biblioteca.

Experiência: Coleção automática de rastreamentos de pilha . A resposta aceita faz algum truque do gdb. No entanto, parece que o libsegfault, (ou se você quiser coletar mais informações o apport um) será o melhor "mostre-me o segfault"