Firefox se fige avec 100% d'utilisation du processeur pendant 30 secondes lors du lancement de Chromium

Récemment, j'ai commencé à observer ce phénomène très déroutant et ennuyeux, pour ne pas dire un comportement inquiétant lorsque Firefox est ouvert, puis que je lance Chromium:

Pendant environ 30 secondes, les processus enfants de Firefox consommeraient toutes les ressources CPU disponibles, entraînant l'arrêt du rendu des sites Web (la page déjà affichée se bloque, les nouvelles pages affichent une page blanche avec un cercle de rotation gris) tandis que la fenêtre globale est toujours réactive (menus, défilement des pages , changer d'onglet, même des pages internes comme about: config ou about: préférences work ...). Le chrome lui-même ne présente aucun symptôme. La résiliation immédiate de Chromium, alors que Firefox tourne, n'arrête pas le comportement plus rapidement.

La même chose se produit avec mon profil Firefox habituel, un tout nouveau profil Firefox intact sans aucun module complémentaire, etc., Firefox a démarré en mode sans échec avec les modules complémentaires désactivés et Firefox a démarré en mode privé. Similaire à Chromium, je peux le lancer avec mon profil habituel, en mode navigation privée ou avec un profil temporaire, générant toujours les mêmes résultats.

Il ne se passe rien d'étrange lorsque Chromium est en cours d'exécution et que j'ouvre Firefox.

Lors du lancement de Firefox à partir d'un terminal, je reçois parfois des messages comme ceux-ci lorsque je le quitte alors qu'il tourne (notez la ligne d'erreur du tuyau mentionnant un chrome 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

Étrangement, je ne pouvais pas reproduire ce comportement dans un compte invité ou un compte régulier (admin) nouvellement créé.

Quelques spécifications système (mises à jour):

• Ubuntu 16.04 (64 bits)
• Firefox 62.0 + build2-0ubuntu0.16.04.5 63.0 + build2-0ubuntu0.16.04.2
• Chrome 69.0.3497.81-0ubuntu0.16.04.1 70.0.3538.77-0ubuntu0.16.04.1
• fontconfig 2.11.94-0ubuntu1.1
• Matériel graphique: carte graphique intégrée Intel SkyLake (i5-6200U) + Nvidia GeForce 940M
  Actuellement, j'ai le nvidia-410pilote installé, mais je suis passé au profil Intel prime. Comment puis-je continuer à dépanner et à résoudre ce problème?

J'ai créé un profil de performances avec l'extension Gecko Profiler, installée sur un nouveau profil Firefox propre sur mon compte Ubuntu habituel. Il peut être trouvé ici: https://perfht.ml/2zpTWsh - Le laps de temps qui ne répond pas avec 100% d'utilisation du processeur devrait correspondre à peu près à la zone en surbrillance sur les chronologies Content Proc, de 18 à 56 secondes environ.

J'ai créé un rapport de bogue Mozilla pour ce problème: https://bugzilla.mozilla.org/show_bug.cgi?id=1504461

Mise à jour importante: Apparemment, mon rapport de bogue était un doublon de https://bugzilla.mozilla.org/show_bug.cgi?id=1495900 , qui le décrit fontconfigcomme le coupable. Il semble que le démarrage de Chromium modifie la configuration des polices d'une manière ou d'une autre, ce qui déclenche un rechargement complet dans Firefox. Cela correspond au rapport de profilage des performances et s'aligne également sur la façon dont les anciennes mises à jour des packages de polices ont déclenché le même type de gel.

Avez-vous des idées sur la façon dont je peux faire en sorte que les trois (Firefox, Chrome, fontconfig) se comportent bien les uns avec les autres?

TL; DR: C'est un problème avec fontconfigavant la version 2.13. Il peut être corrigé en mettant à niveau le package vers 2.13 ou supérieur (bien que je n'aie pas pu trouver de fournisseur approprié). Vous pouvez également examiner tous vos dossiers et fichiers de configuration liés aux polices dans votre répertoire personnel et tester si la suppression de l'un d'eux résout votre problème. Pour moi, renommer a ~/.fontsfait l'affaire.

Après avoir pris connaissance des rapports de bogues https://bugzilla.mozilla.org/show_bug.cgi?id=1495900 et https://bugzilla.mozilla.org/show_bug.cgi?id=1411338, il devient assez clair que le problème doit être causée par fontconfig.

D'une manière ou d'une autre, lorsque Chromium démarre, il déclenche un changement dans la base de données de polices (???), ce qui oblige Firefox - s'il est en cours d'exécution - à ré-analyser le système de fichiers pour les polices, ce qui entraîne l'utilisation du processeur et un gel temporaire.

Apparemment, la mise à jour du fontconfigpackage de la version 2.11 à 2.13 (la version fournie par exemple dans Ubuntu 18.10) devrait résoudre le problème, mais je n'ai trouvé aucun moyen facile d'obtenir cette version le 16.04, sans casser les dépendances de nombreux autres packages que j'ai installés.

Donc, comme le problème est limité à mon compte d'utilisateur, j'ai examiné la configuration et les dossiers des polices locales de mon utilisateur. Il y a tout un gâchis de différents répertoires liés à la police pour être honnête, y compris ~/.fonts, ~/.local/share/fonts, ~/.local/share-font-manager, ~/.config/font-manager, ~/.cache/font-manager, ~/.cache/fontconfiget quelques fichiers de configuration plus et des trucs de police spécifiques à l' application.

J'ai commencé par supprimer (renommer) le ~/.fontsdossier, car il ne semblait pas contenir quoi que ce soit d'utile de toute façon, et un simple touch ~/.fonts/Library/avant cela a déclenché la mauvaise conduite de Firefox. Après la disparition de ce dossier, le problème s'est également posé lors du lancement de Chromium. \ o /

Contexte

Il a été proposé ce Firefox Bug 1492360: utilisation élevée du processeur lors de l'ouverture de Firefox avant chrome / chrome . Il s'agit d'un doublon du bogue 1495900: le démarrage de Chrome entraîne le blocage des processus de contenu Firefox pendant environ deux minutes, en raison de la nouvelle analyse de la police FontConfig (FcInitReinitialize) , est le coupable.

Mais je suis aussi sur Firefox:

Et quand j'ouvre Chrome:

Je ne vois aucune performance affectée aux processeurs.

C'est peut-être contraire à votre morale, mais vous pouvez peut-être essayer d'installer google-chrome-stablecomme je l'ai fait. Ensuite, refaites le test. S'il n'y a pas de pic d'utilisation du processeur à 100%, un rapport de bogue peut être déposé entre Chromium et Chrome.

Je suis sur Ubuntu 16.04.5 LTS. Bien que le noyau soit actuellement une 4.14.78chaîne LTS, je ne pense pas que cela ait quelque chose à voir avec cela, car je n'ai pas non plus remarqué de coups de processeur sur les noyaux précédents.

La seule fois où je vois tous les CPU à 100%, c'est pendant update-initramfs.

fontconfig verson

Dans le rapport de bug, il est révélé:

$ 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

Dans ma version non buggée (peut-être à cause de l'absence de polices locales):

$ 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

Je suis à une 2.11.94version antérieure à la version de rapport de bogue 2.12. Dans le rapport de bogue, la mise à niveau 2.13est une solution recommandée, mais OP mentionné dans les commentaires, ce n'est pas possible. En tant que tel, cela 2.11.94 pourrait être une option.

À en juger par le journal, il semble que Firefox utilise l'IPC synchrone (communication inter-processus) pour une raison quelconque. Il existe des indicateurs dans Firefox pour activer explicitement l'IPC synchrone (par exemple: network.cookie.ipc.sync). L'un d'eux pourrait être activé. Vous pouvez y accéder depuis la page about: config

Le retard serait alors le résultat d'une attente de Firefox sur la réponse. Puisqu'il n'y a pas de charge lorsque Chromium a fini de démarrer ou n'est pas en cours d'exécution, il y a une réponse immédiate.

En relation: https://bugzilla.mozilla.org/show_bug.cgi?id=1331680

Je ne sais pas si la suggestion suivante fonctionnera ou non. Vous pouvez essayer. Essayez de supprimer complètement le chrome et firefox (conservez les fichiers .deb bien sûr) en utilisant Synaptic Package Manager. Après cela, vérifiez s'il existe des dépendances cassées. Corrigez-les à l'aide de synaptique (le cas échéant). Vérifiez maintenant l'utilisation du processeur (j'utilise Powertop). Enfin, effectuez une nouvelle réinstallation des navigateurs.

Remarque: Ces choses sont généralement ce que je fais en cas d'anomalies spécifiques. Je me souviens avoir fait face à un problème légèrement similaire il y a un an. Cela a été résolu de cette façon.

Sur Ubuntu 16.04, la suppression du dossier vide l'a ~/.local/share/fontsrésolu dans mon cas.