Firefox зависает при 100% загрузке процессора в течение 30 секунд при запуске Chromium

Недавно я начал наблюдать это очень запутанное и раздражающее, не говоря уже о тревожном поведении, когда у вас открыт Firefox, а затем запущен Chromium:

В течение примерно 30 секунд дочерние процессы Firefox будут потреблять все доступные ресурсы ЦП, в результате чего веб-сайты прекращают рендеринг (уже отображаемая страница зависает, на новых страницах отображается белая страница с серым вращающимся кружком), пока общее окно все еще реагирует (меню, прокрутка страницы , переключение вкладок, даже внутренних страниц, таких как about: config или about: settings работают ...). Сам хром не проявляет никаких симптомов. Немедленное прекращение Chromium, пока Firefox вращается, не останавливает поведение быстрее.

То же самое происходит с моим обычным профилем Firefox, совершенно новым, нетронутым профилем Firefox без каких-либо надстроек и т. Д., Firefox запускается в безопасном режиме с отключенными надстройками, а Firefox запускается в приватном режиме. Аналогично для Chromium, я могу запустить его со своим обычным профилем, в режиме инкогнито или с временным профилем, всегда генерируя одинаковые результаты.

Ничего странного не происходит, когда работает Chromium, и я открываю Firefox.

При запуске Firefox из терминала я иногда получаю подобные сообщения при выходе из него, когда он вращается (обратите внимание на строку с ошибкой канала, в которой упоминается какой-то хром-ipc ...):

ExceptionHandler::GenerateDump cloned child 32165
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
[Parent 26520, Gecko_IOThread] WARNING: pipe error (52): Connection reset by peer: file /build/firefox-8oo9jx/firefox-62.0+build2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
ExceptionHandler::GenerateDump cloned child 32274
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child

Странно, я не мог воспроизвести это поведение в гостевой учетной записи или недавно созданной обычной (администраторской) учетной записи.

Некоторые системные характеристики (обновлено):

• Ubuntu 16.04 (64 бит)
• Fire Fox 62,0 + build2-0ubuntu0.16.04.5 63,0 + build2-0ubuntu0.16.04.2
• хром 69.0.3497.81-0ubuntu0.16.04.1 70.0.3538.77-0ubuntu0.16.04.1
• fontconfig 2.11.94-0ubuntu1.1
• Графическое оборудование: интегрированная графика Intel SkyLake (i5-6200U) + Nvidia GeForce 940M
  В настоящее время у меня nvidia-410установлен драйвер, но я переключился на основной профиль Intel. Как я могу дополнительно устранить неполадки и устранить эту проблему?

Я создал профиль производительности с помощью Gecko Profiler Extension, установленного в чистом свежем профиле Firefox на моей обычной учетной записи Ubuntu. Его можно найти здесь: https://perfht.ml/2zpTWsh - время отклика при 100% загрузке ЦП должно примерно соответствовать выделенной области на шкале времени Content Proc, примерно от 18 до 56 с.

Я создал отчет об ошибках Mozilla для этой проблемы: https://bugzilla.mozilla.org/show_bug.cgi?id=1504461

Важное обновление: очевидно, мой отчет об ошибке был дубликатом https://bugzilla.mozilla.org/show_bug.cgi?id=1495900 , который указывает fontconfigна виновника. Похоже, что запуск Chromium каким-то образом вносит изменения в конфигурацию шрифта, что вызывает полную перезагрузку в Firefox. Это соответствует отчету о профилировании производительности, а также согласуется с тем, как прежние обновления пакетов шрифтов вызывали такой же тип зависания.

Любые идеи, как я могу заставить эти три (Firefox, Chromium, fontconfig) вести себя хорошо друг с другом?

TL; DR: это проблема fontconfigдо версии 2.13. Это можно исправить, обновив пакет до версии 2.13 или выше (хотя я не смог найти подходящего поставщика). В качестве альтернативы, проверьте все ваши связанные со шрифтами папки и файлы конфигурации в вашем домашнем каталоге и проверьте, если удаление какой-либо из них решит вашу проблему. Для меня переименование ~/.fontsсделало свое дело.

После изучения отчетов об ошибках https://bugzilla.mozilla.org/show_bug.cgi?id=1495900 и https://bugzilla.mozilla.org/show_bug.cgi?id=1411338 становится довольно ясно, что проблема должна быть вызвано fontconfig.

Каким-то образом, когда Chromium запускается, он вызывает изменение в базе данных шрифтов (???), что заставляет Firefox - если он в данный момент работает - каким-то образом повторно сканировать файловую систему на наличие шрифтов, что приводит к использованию ЦП и временному зависанию.

Очевидно, обновление fontconfigпакета с версии 2.11 до 2.13 (версия, поставляемая, например, в Ubuntu 18.10) должно исправить проблему, но я не нашел простого способа получить эту версию 16.04, не нарушая зависимости множества других пакетов, которые я установил.

Так как проблема ограничена моей учетной записью, я изучил конфигурацию локальных шрифтов и папки моего пользователя. Там довольно беспорядок различных шрифтов связанных каталогов , честно говоря, в том числе ~/.fonts, ~/.local/share/fonts, ~/.local/share-font-manager, ~/.config/font-manager, ~/.cache/font-manager, ~/.cache/fontconfigи еще несколько конфигурационных файлов и приложения конкретных вещей шрифта.

Я начал с удаления (переименования) ~/.fontsпапки, так как она, похоже, в любом случае не содержала ничего полезного, и простое touch ~/.fonts/Library/до этого вызвало неправильное поведение Firefox. После того, как эта папка исчезла, возникла проблема при запуске Chromium. \ о /

Фон

Было предложено это Firefox Bug 1492360: высокая загрузка ЦП при открытии Firefox до Chrome / Chromium . Это дубликат ошибки 1495900: запуск Chrome заставляет процессы содержимого Firefox зависать примерно на две минуты из-за повторного сканирования шрифта FontConfig (FcInitReinitialize) , которое является виновником.

Но я тоже на Firefox:

И когда я открываю Chrome:

Я не вижу никакого снижения производительности процессоров.

Это может быть против вашей морали, но, возможно, вы можете попробовать установить, google-chrome-stableкак у меня. Затем сделайте тест снова. Если при загрузке процессора не происходит скачка на 100%, между Chromium и Chrome может быть отправлено сообщение об ошибке.

Я на Ubuntu 16.04.5 LTS. Хотя ядро ​​в настоящее время является 4.14.78цепочкой LTS, я не думаю, что это имеет какое-либо отношение к нему, так как я не замечал попадания ЦП в предыдущие ядра.

Единственный раз, когда я вижу все процессоры на 100%, это во время update-initramfs.

fontconfig Версон

В отчете об ошибке обнаружено:

$ dpkg -l 'fontconfig*' | grep "^ii"
ii  fontconfig        2.12.6-0ubuntu2 amd64        generic font configuration library - support binaries
ii  fontconfig-config 2.12.6-0ubuntu2 all          generic font configuration library - configuration

В моей версии без ошибок (может быть из-за отсутствия локальных шрифтов):

$ dpkg -l 'fontconfig*' | grep "^ii"
ii  fontconfig        2.11.94-0ubuntu1.1 amd64        generic font configuration library - support binaries
ii  fontconfig-config 2.11.94-0ubuntu1.1 all          generic font configuration library - configuration

Я нахожусь в 2.11.94версии ранее, чем 2.12версия отчета об ошибке . В отчете об ошибках обновление 2.13является рекомендуемым решением, но в комментариях к OP это невозможно. Как таковой 2.11.94 может быть вариант.

Судя по журналу, похоже, что Firefox по какой-то причине использует синхронный IPC (межпроцессное взаимодействие). В Firefox есть флаги для явного включения синхронного IPC (например, network.cookie.ipc.sync). Один из них может быть включен. Вы можете получить к ним доступ со страницы about: config

Задержка может быть результатом того, что firefox ожидает ответа. Поскольку нет никакой нагрузки, когда Chromium закончил запуск или не активно работает, существует немедленный ответ.

Связанный: https://bugzilla.mozilla.org/show_bug.cgi?id=1331680

Не знаю, сработает ли следующее предложение или нет. Вы можете попробовать. Попробуйте полностью удалить chromium и firefox (конечно, сохраните файлы .deb) с помощью Synaptic Package Manager. После этого проверьте, есть ли нарушенные зависимости. Исправьте их, используя synaptic (если есть). Теперь проверьте использование процессора (я использую Powertop). Наконец, сделайте новую переустановку браузеров.

Примечание: эти вещи, как правило, то, что я делаю в случае определенных отклонений. Я помню, что столкнулся с немного похожей проблемой год назад. Это было решено таким образом.

В Ubuntu 16.04 удаление пустой папки ~/.local/share/fontsрешило проблему в моем случае.