Ошибка Mozilla (thunderbird an / or firefox), принося хром с ней

Симптомы : сбой Firefox и Thunderbird прерывается, обычно за ним следует хром.

Как только произойдет сбой, перезапуск приведет к очередному сбою почти сразу, пока система не перезагрузится.

Я заменил все части оборудования, сделал полную переустановку дважды. Эта проблема ТОЛЬКО возникает на одной из моих систем (к сожалению, моя главная). У меня есть другие системы Ubuntu, которые работают нормально.

Операционная система:

  • Ubuntu 16.04
  • но это произошло и в 15.10 (но не 15.04, IIRC)

Оборудование:

  • AMD FX 9370 (8 ядро)
  • ОЗУ: 32 ГБ
  • Системный диск: Crucial CT256MX (256 ГБ)
  • диск данных: Seagate ST2000dx (2Tb)
  • Графика: AMD FirePro W4100

Устранение неполадок до сих пор:

Я проверил обычных подозреваемых (ядро, syslog, auth и т. Д.) В / var / logs для ошибок, но не нашел ничего похожего на дымящийся пистолет.

Любая помощь оценивается.

После нескольких недель тестирования, регистрации, анализа и даже использования бета-версии SolarWinds NPM и SAM проблема, похоже, является многоэмиссионным оборудованием.

Я удалил все плагины из FF и обнаружил, что мне удалось работать дольше, но все равно приходилось сбой каждые 24-48 часов.

Как ни странно, когда я запустил две виртуальные виртуальные машины VirtualBox, я обнаружил, что могу остаться и работать в течение 48-72 часов, прежде чем потребуется перезагрузка.

Но проблемы остались, и я решил вернуться и проверить оборудование (опять же). Я нашел:

1) Основной (загрузочный диск / ОС) SSD имел ошибку контроллера

2) 1 из 4 палок ОЗУ имело массовые ошибки на нем. Мне пришлось запускать MemTest86 на каждом отдельном тике (выключите ПК, удалите все, кроме 1 палки, загрузитесь на CD, запустите MemTest86, повторите промывку ополаскивания).

Смена жесткого диска и удаление этой плохой палки ОЗУ позволили мне продолжать работать и работать в течение 4 дней и никаких признаков проблемы. Запасная оперативная память находится в пути (я благодарен Crucial за их пожизненную гарантию и беспроблемный процесс RMA).

Вы пробовали смотреть на здоровье диска? Может быть более актуальная утилита, но smartctl должен делать трюк (как root):

 smartctl -a /dev/sda | more 

Вы создали много данных, и мы не получили много информации. Вероятно, вы потратили больше времени на поиски более ужасных вещей в dmesg, чем я, и обнаружили, что никто ничего не заметил. Если вы по-прежнему готовы упорствовать, вот что-то немного меньше сена.

Гипотеза. Если есть проблема с оборудованием, он должен проявлять себя с одинаковым набором вызовов ядра или libc API каждый раз. то есть:

  • Плохой диск или контроллер диска будет постоянно создавать трассировки стека, заканчивающиеся на open (), access (), read (), write () и т. Д.
  • Плохая память обычно терпит неудачу в malloc () / free () (но это может усложниться).
  • Плохой ЦП будет вести себя беспорядочно
  • Плохой видеодрайвер создаст какую-то неизвестную трассировку стека, но, надеюсь, что-то интересное, чтобы привлечь внимание разработчика ядра умнее нас
  • Со стороны программного обеспечения mozilla chrome и thunderbird, производящие трассировки стека, проходящие через те же пользовательские наземные библиотеки, указывают, но могут быть в этой библиотеке.

Эксперимент: автоматическая сборка следов стека . Принятый ответ делает некоторые издевательства gdb. Тем не менее, кажется, что libsegfault (или если вы хотите собрать больше информации, апорт один) будет лучшим «показать мне segfault»,