Firefox friert beim Starten von Chromium 30 Sekunden lang bei 100% CPU-Auslastung ein

Kürzlich habe ich angefangen, dieses sehr verwirrende und nervige Verhalten zu beobachten, ganz zu schweigen von dem besorgniserregenden Verhalten, wenn Firefox geöffnet und dann Chromium gestartet wird:

Die untergeordneten Prozesse von Firefox verbrauchen etwa 30 Sekunden lang alle verfügbaren CPU-Ressourcen und führen dazu, dass Websites nicht mehr gerendert werden (bereits angezeigte Seite friert ein, neue Seiten zeigen eine weiße Seite mit grauem Kreis), während das Gesamtfenster noch reagiert (Menüs, Bildlauf durch Seiten) , Tabs wechseln, auch interne Seiten wie about: config oder about: preferences funktionieren ...). Chrom selbst zeigt keine Symptome. Wenn Sie Chromium sofort wieder beenden, während Firefox sich dreht, wird das Verhalten nicht schneller beendet.

Das gleiche passiert mit meinem regulären Firefox-Profil, einem brandneuen, unberührten Firefox-Profil ohne Add-Ons usw., Firefox wurde im abgesicherten Modus mit deaktivierten Add-Ons gestartet und Firefox wurde im privaten Modus gestartet. Ähnlich wie bei Chromium kann ich es mit meinem regulären Profil im Inkognito-Modus oder mit einem temporären Profil starten und dabei immer die gleichen Ergebnisse erzielen.

Es passiert nichts Ungewöhnliches, wenn Chromium ausgeführt wird und ich Firefox öffne.

Wenn ich Firefox von einem Terminal aus starte, erhalte ich manchmal die folgenden Meldungen, wenn ich es beim Drehen beende (beachten Sie die Pipe-Fehlerzeile, in der etwas Chrom-IPC erwähnt wird ...):

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

Seltsamerweise konnte ich dieses Verhalten in einem Gastkonto oder einem neu erstellten regulären Konto (Admin-Konto) nicht reproduzieren.

Einige Systemspezifikationen (aktualisiert):

• Ubuntu 16.04 (64 Bit)
• Feuerfuchs 62.0 + build2-0ubuntu0.16.04.5 63.0 + build2-0ubuntu0.16.04.2
• Chrom 69.0.3497.81-0ubuntu0.16.04.1 70.0.3538.77-0ubuntu0.16.04.1
• fontconfig 2.11.94-0ubuntu1.1
• Grafikhardware: Intel SkyLake integrierte Grafik (i5-6200U) + Nvidia GeForce 940M
  Derzeit habe ich den nvidia-410Treiber installiert, aber auf das Intel Prime-Profil umgestellt. Wie kann ich dieses Problem weiter beheben und beheben?

Ich habe mit der Gecko Profiler-Erweiterung ein Leistungsprofil erstellt, das auf meinem regulären Ubuntu-Konto auf einem sauberen, frischen Firefox-Profil installiert wurde. Es kann hier gefunden werden: https://perfht.ml/2zpTWsh - Der nicht reagierende Zeitrahmen mit 100% CPU-Auslastung sollte in etwa dem hervorgehobenen Bereich in den Content Proc-Zeitplänen entsprechen, von ungefähr 18 bis 56 Sekunden.

Ich habe einen Mozilla-Fehlerbericht für dieses Problem erstellt: https://bugzilla.mozilla.org/show_bug.cgi?id=1504461

Wichtiges Update: Anscheinend war mein Fehlerbericht ein Duplikat von https://bugzilla.mozilla.org/show_bug.cgi?id=1495900 , was auf fontconfigden Täter hinweist . Scheint, als würde Chromium die Schriftartkonfiguration irgendwie ändern, was ein vollständiges Neuladen in Firefox auslöst. Dies passt zum Bericht zur Leistungsprofilerstellung und richtet sich auch danach, wie frühere Aktualisierungen von Schriftartenpaketen dieselbe Art des Einfrierens ausgelöst haben.

Irgendwelche Ideen, wie ich die drei (Firefox, Chromium, fontconfig) dazu bringen kann, sich gut zusammen zu verhalten?

TL; DR: Es ist ein Problem mit fontconfigvor Version 2.13. Es kann behoben werden, indem das Paket auf 2.13 oder höher aktualisiert wird (obwohl ich keinen geeigneten Anbieter gefunden habe). Überprüfen Sie alternativ alle Ihre mit Zeichensätzen zusammenhängenden Ordner und Konfigurationsdateien in Ihrem Ausgangsverzeichnis und testen Sie, ob das Entfernen eines dieser Ordner das Problem behebt. Für mich hat das Umbenennen ~/.fontsden Trick getan.

Nachdem Sie die Fehlerberichte https://bugzilla.mozilla.org/show_bug.cgi?id=1495900 und https://bugzilla.mozilla.org/show_bug.cgi?id=1411338 gelesen haben, wird ziemlich klar, dass das Problem sein muss verursacht durch fontconfig.

Irgendwie wird beim Start von Chromium eine Änderung in der Zeichensatzdatenbank (???) ausgelöst, die Firefox veranlasst, das Dateisystem - falls gerade ausgeführt - erneut nach Zeichensätzen zu durchsuchen, was zur CPU-Auslastung und zum vorübergehenden Einfrieren führt.

Offensichtlich sollte das Aktualisieren des fontconfigPakets von Version 2.11 auf 2.13 (die Version, die z. B. in Ubuntu 18.10 ausgeliefert wurde) das Problem beheben, aber ich fand keine einfache Möglichkeit, diese Version auf 16.04 zu bekommen, ohne die Abhängigkeiten vieler anderer von mir installierter Pakete zu zerstören.

Da das Problem auf mein Benutzerkonto beschränkt ist, habe ich die lokale Schriftartenkonfiguration und die Ordner meines Benutzers überprüft. Es ist schon ein Durcheinander von verschiedenen Schriftbezogene Verzeichnissen ehrlich zu sein, einschließlich ~/.fonts, ~/.local/share/fonts, ~/.local/share-font-manager, ~/.config/font-manager, ~/.cache/font-manager, ~/.cache/fontconfigund noch ein paar Konfigurationsdateien und anwendungsspezifische Schrift Zeug.

Ich begann damit, den ~/.fontsOrdner zu entfernen (umzubenennen) , da er ohnehin nichts Nützliches zu enthalten schien, und ein einfaches touch ~/.fonts/Library/Vorher löste das Fehlverhalten von Firefox aus. Nachdem dieser Ordner nicht mehr vorhanden war, trat beim Starten von Chromium das Problem auf. \Ö/

Hintergrund

Es wurde der Firefox Bug 1492360 vorgeschlagen: Hohe CPU-Auslastung beim Öffnen von Firefox vor Chrom / Chrom . Dies ist ein Duplikat von Bug 1495900: Durch das Starten von Chrome bleiben Firefox-Inhaltsprozesse etwa zwei Minuten lang hängen, da das erneute Scannen von FontConfig-Schriftarten (FcInitReinitialize) der Schuldige ist.

Aber ich bin auch bei Firefox:

Und wenn ich Chrome öffne:

Ich sehe keine Leistungseinbußen bei den CPUs.

Es mag gegen deine Moral sein, aber vielleicht kannst du versuchen, es so zu installieren, google-chrome-stablewie ich es getan habe. Führen Sie dann den Test erneut durch. Wenn die CPU-Auslastung nicht auf 100% ansteigt, kann ein Fehlerbericht zwischen Chromium und Chrome erstellt werden.

Ich bin auf Ubuntu 16.04.5 LTS. Obwohl der Kernel zur Zeit eine 4.14.78LTS-Kette ist, habe ich nichts damit zu tun, da ich auch bei früheren Kerneln keine CPU-Treffer bemerkt habe.

Das einzige Mal, dass ich alle CPUs bei 100% sehe, ist während update-initramfs.

fontconfig verson

Im Fehlerbericht wird Folgendes enthüllt:

$ 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

In meiner nicht fehlerbehafteten Version (könnte aber an keinen lokalen Schriften liegen):

$ 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

Ich habe eine 2.11.94frühere Version als die 2.12Version des Fehlerberichts . In Fehlerberichten 2.13ist ein Upgrade auf eine empfohlene Lösung, aber das in Kommentaren erwähnte OP ist nicht möglich. Als solche 2.11.94 könnte eine Option sein.

Aus dem Protokoll geht hervor, dass Firefox aus irgendeinem Grund synchrones IPC (Inter-Process Communication) verwendet. In Firefox gibt es Flags, mit denen synchroner IPC explizit aktiviert werden kann (z. B. network.cookie.ipc.sync). Eine davon ist möglicherweise aktiviert. Sie können diese aus dem Zugriff config: etwa Seite

Die Verzögerung wäre dann ein Ergebnis des Wartens von Firefox auf die Antwort. Da nach dem Start von Chromium oder wenn Chromium nicht aktiv läuft, keine Last vorhanden ist, erfolgt eine sofortige Reaktion.

Verwandte Themen: https://bugzilla.mozilla.org/show_bug.cgi?id=1331680

Ich weiß nicht, ob der folgende Vorschlag funktioniert oder nicht. Sie können es versuchen. Versuchen Sie, Chrom und Firefox vollständig zu entfernen (behalten Sie die .deb-Dateien natürlich bei), indem Sie Synaptic Package Manager verwenden. Überprüfen Sie anschließend, ob defekte Abhängigkeiten vorhanden sind. Beheben Sie sie mithilfe von Synaptic (falls vorhanden). Überprüfen Sie nun die CPU-Auslastung (ich verwende Powertop). Führen Sie abschließend eine Neuinstallation der Browser durch.

Hinweis: Diese Dinge sind im Allgemeinen das, was ich bei bestimmten Anomalien tue. Ich erinnere mich, dass ich vor einem Jahr ein etwas ähnliches Problem hatte. Es wurde auf diese Weise gelöst.

Unter Ubuntu 16.04 löste das Löschen des leeren Ordners das ~/.local/share/fontsProblem in meinem Fall.