Firefox freezes temporarily at 100% CPU when Chromium is opened

Bug #1856624 reported by ais523
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
Medium
firefox (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

When Firefox is open, and I open Chromium, many features of Firefox fail to work for several seconds. (To reproduce, start with neither Firefox nor Chromium open; open Firefox, and allow one or more web pages to load; then open Chromium; the issue starts a second or two after Chromium is opened.) This is a temporary issue, lasting for several seconds; the length of time it lasts appears to depend on how many open tabs have been viewed since Firefox opened (on my computer, around 10 seconds with 1 tab having been viewed, around a minute with 10 tabs having been viewed). This reproduces even when running Firefox as `firefox -safe-mode`.

While the issue is ongoing (i.e. starting around a second after Chromium is open, and persisting for typically tens of seconds), some features of Firefox work, but most do not:
- Scrolling the current tab short distances succeeds, showing the expected text on the page.
- Scrolling the current tab long distances (several screeenfuls) causes the page to be "cut off" past a certain point, with only a blank background rendering.
- Moving the mouse cursor over a link does not change the mouse cursor (expected behaviour, and behaviour while the issue is not ongoing, is for it to change to a hand shape).
- Changing tab causes the resulting page not to display: rather, a grey background is displayed, and sometimes a loading spinner.
- Changing tab back then causes the original page not to render, as if it were new, despite the fact it was correctly displayed earlier.
- The address bar functions as normal; the issue does not appear to affect address bar functionality.
Additionally, while the issue is ongoing, Firefox uses 100% CPU.

At some point after the issue in question starts, it stops, and all Firefox features return to normal (including any missing or incorrectly rendered page content, which renders again when the issue ends).

The trigger is specifically the act of opening Chromium: Firefox can function just fine once the issue ends, even if Chromium is still open, and functions just fine if Chromium is opened first.

I have an (unconfirmed) theory that opening Chromium is causing some operation within Firefox to become very slow, using up all the CPU time, and the other observed misbehaviours within Firefox are a consequence of how slowly it is running; however, I've listed them all anyway in case it provides clarity into what the specific nature of the bug is.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: firefox 71.0+build5-0ubuntu0.18.04.1
ProcVersionSignature: Ubuntu 5.0.0-37.40~18.04.1-generic 5.0.21
Uname: Linux 5.0.0-37-generic x86_64
AddonCompatCheckDisabled: False
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ais523 1800 F.... pulseaudio
BuildID: 20191205184924
Channel: Unavailable
CurrentDesktop: X-Cinnamon
Date: Tue Dec 17 00:29:10 2019
ExecutablePath: /usr/lib/firefox/firefox
ForcedLayersAccel: False
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
IncompatibleExtensions:
 English (South Africa) Language Pack - <email address hidden>
 Français Language Pack - <email address hidden>
 English (GB) Language Pack - <email address hidden>
 Default - {972ce4c6-7e08-4474-a285-3208198ce6fd}
InstallationDate: Installed on 2019-11-11 (35 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
IpRoute:
 default via 192.168.1.1 dev wlp2s0 proto dhcp metric 600
 169.254.0.0/16 dev wlp2s0 scope link metric 1000
 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 600
MostRecentCrashID: bp-935fd166-3720-454f-8fe5-0a1752140227
PrefErrors: Unexpected character ',' before close parenthesis @ /usr/lib/firefox/omni.ja:greprefs.js:722
PrefSources: prefs.js
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
Profiles: Profile0 (Default) - LastVersion=71.0/20191205184924 (In use)
RunningIncompatibleAddons: True
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/30/2019
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.5.1
dmi.board.name: 0DDKKC
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.5.1:bd05/30/2019:svnDellInc.:pnInspiron3583:pvr:rvnDellInc.:rn0DDKKC:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.family: Inspiron
dmi.product.name: Inspiron 3583
dmi.product.sku: 08CA
dmi.sys.vendor: Dell Inc.

Revision history for this message
In , Timj-8 (timj-8) wrote :

Created attachment 9078136
Screenshot from 2019-07-15 15-33-31.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

1. Start Firefox-68.0 (fresh profile) on Ubuntu 18.04.2 LTS with X11 on Linux 4.15.0-50-generic x86_64. (Note, this behaviour has also been observed with FF-67 versions.)

2. Start an application with libchromiumcontent >= 69.0.3497.128, e.g. by starting electron-4 (v69.0.3497.128) or electron-5 (v73.0.3683.121) or gooogle-chrome (v75.0.3770.100). Example:
  npm i electron@4 && node_modules/electron/dist/electron

3. The second application can be closed immediately, starting it is enough already to trigger FF.

Note, libchromiumcontent v66.0.3359.181 (from electron-3) does *NOT* trigger FF.

Actual results:

Firefox uses up *all* CPU cores (8 here) at 100% for several seconds, observable e.g. via `htop` with thread view.
Even exiting the libchromiumcontent using application immediately doesn't cure FF from overloading all CPU cores for several more seconds.
If you happen to have `about:performance` opened during the overload situation, it will display *only* the "Task Manager" row, until it recovers from the overload situation, after that point it also lists the other rows for additional tabs again.

Expected results:

A) FF CPU usage should not be triggered by libchromiumcontent using applications.
B) Tab "about:performance" should actually indicate where the CPU cycles are being wasted.

Revision history for this message
In , Aflorinescu (aflorinescu) wrote :

Thanks Tim for the report! Could you please be more specific with the steps to reproduce?

npm i electron@4 && node_modules/electron/dist/electron opens for me:
Electron v4.2.8Chromium v69.0.3497.128Node v10.11.0v8 v6.9.427.31-electron.0

Not sure how to trigger firefox to load when starting electron.

Revision history for this message
In , Timj-8 (timj-8) wrote :

(In reply to Adrian Florinescu [:adrian_sv] from comment #1)
> Thanks Tim for the report! Could you please be more specific with the steps to reproduce?
>
> npm i electron@4 && node_modules/electron/dist/electron opens for me:
> Electron v4.2.8Chromium v69.0.3497.128Node v10.11.0v8 v6.9.427.31-electron.0
>
> Not sure how to trigger firefox to load when starting electron.

Hi Adrian,
starting electrong (or a new version of google-chrome) is enough already.

If you cannot notice the overload (are you using X11?) can you give it a shot under Ubuntu 18.04?
Or let me know what dist you're testing on, so I can give that a shot as well.

Revision history for this message
In , Aflorinescu (aflorinescu) wrote :

Apologies, I've tested with Ubuntu 16.04 and I haven't noticed a Firefox process starting or any overload; that's why I assumed I was missing a step or two. Sure, will give it a try on Ubuntu 18.04 and post back if I get a positive result.

Revision history for this message
In , Aflorinescu (aflorinescu) wrote :

Slipped my todo list, adding a NI to get back to this.

Revision history for this message
In , Timj-8 (timj-8) wrote :
Download full text (3.3 KiB)

I'm still seeing massive CPU overload with Firefox 68.0.1 and e.g. electron-6.

Attaching gdb to a running /usr/lib/firefox/firefox shows that, as soon as electron is started, the firefox process gets a *massive* amount of SIGSYS signals. Apparently all due to looking for font files. And each firefox process does gets these signals which seems to cause the overload, we're talking about ca 12000 signals on my system, probably due to the great number of font files I have installed here. Here are some excerpts from the debugging session:

Thread 1 "Web Content" received signal SIGSYS, Bad system call.
0x00007f8d210fd775 in __GI___xstat (vers=<optimized out>, name=0x7f8cff489aa0 "/etc/fonts/fonts.conf", buf=0x7fffe2acfb70) at ../sysdeps/unix/sysv/linux/wordsize-64/xstat.c:35
Thread 1 "Web Content" received signal SIGSYS, Bad system call.
0x00007f8d210fd775 in __GI___xstat (vers=<optimized out>, name=0x7f8cff678d00 "/etc/fonts/conf.d", buf=0x7fffe2acfb70) at ../sysdeps/unix/sysv/linux/wordsize-64/xstat.c:35

etc. Other locations/syscalls:

0x00007f8d210fd775 in __GI___xstat (vers=<optimized out>, name=0x7f8d056b6a30 "/etc/fonts/conf.d/10-antialias.conf", buf=0x7fffe2acfb70)
    at ../sysdeps/unix/sysv/linux/wordsize-64/xstat.c:35
0x00007f8d210fd775 in __GI___xstat (vers=<optimized out>, name=0x7f8d056b6b20 "/etc/fonts/conf.d/10-hinting-slight.conf", buf=0x7fffe2acfb70)
    at ../sysdeps/unix/sysv/linux/wordsize-64/xstat.c:35
0x00007f8d210fd775 in __GI___xstat (vers=<optimized out>, name=0x7f8d056b6b50 "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", buf=0x7fffe2acfb70)
0x00007f8d210fd775 in __GI___xstat (vers=<optimized out>, name=0x7f8d056b6b80 "/etc/fonts/conf.d/11-lcdfilter-default.conf", buf=0x7fffe2acfb70)
0x00007f8d210fe247 in __access (file=0x7f8cff695d40 "/etc/fonts/conf.d/20-unhint-small-dejavu-lgc-sans.conf", type=4) at ../sysdeps/unix/sysv/linux/access.c:27
0x00007f8d210fdd19 in __libc_open64 (file=0x7f8cff695ec0 "/etc/fonts/conf.d/20-unhint-small-dejavu-lgc-serif.conf", oflag=524288) at ../sysdeps/unix/sysv/linux/open64.c:47
0x00007f8d210fdd19 in __libc_open64 (file=0x7f8cff443c40 "/var/cache/fontconfig//3830d5c3ddfd5cd38a049b759396e72e-le64.cache-7", oflag=524290)
0x00007f8d210fd775 in __GI___xstat (vers=<optimized out>, name=0x7f8cff69bc40 "/usr/share/texmf/fonts/opentype/public/lm/lmmonocaps10-regular.otf", buf=0x7fffe2acf9b0)
0x00007f8d21b95dae in __libc_open64 (file=0x7f8cff6f89c0 "/usr/share/texmf/fonts/opentype/public/lm/lmroman9-italic.otf", oflag=0) at ../sysdeps/unix/sysv/linux/open64.c:47
0x00007f8d21b95dae in __libc_open64 (file=0x7f8cff658d80 "/usr/share/fonts/cMap/.resource/Identity-UTF16-H", oflag=0) at ../sysdeps/unix/sysv/linux/open64.c:47
0x00007f8d210fe247 in __access (file=0x7f8d05880060 "/var", type=0) at ../sysdeps/unix/sysv/linux/access.c:27
0x00007f8d210fe247 in __access (file=0x7f8d05880068 "", type=0) at ../sysdeps/unix/sysv/linux/access.c:27

etcpp. There are literally thausands of "received signal SIGSYS, Bad system call." messages. The last line pasted above looks interesting also, note that the path is empty, like some script going bonkers...

So it's probably something in recent libchromiumcontent version...

Read more...

Revision history for this message
In , Zhart (zhart) wrote :

The same problem.
Firefox 68.* and Chrom*/Electron on Ubuntu 16.04 and Ubuntu 19.04.

Revision history for this message
In , David Lechner (dlech) wrote :
Revision history for this message
In , David Lechner (dlech) wrote :
Revision history for this message
In , Timj-8 (timj-8) wrote :

(In reply to David Lechner (:dlech) from comment #8)
> More info: https://askubuntu.com/questions/1076412/firefox-freezing-with-100-cpu-usage-for-30-seconds-when-launching-chromium

Thank you for the links. One of the discussion comments suggest the following to also trigger the CPU burning in FF:

    mkdir -p ~/.fonts/Library/ && touch ~/.fonts/Library/

That actually works for me, *without* starting any libchromiumcontent app, so it's indeed due to fontconfig.

I just installed fontconfig+libfontconfig1 2.13.1-2ubuntu2 (the disco packages work on bionic), and that majorly reduces the problem. If Firefox has several tabs opened, there is still a spike that can be seen in CPU usage when libchromiumcontent starts (or with touch ~/.fonts/Library/), but its now only around 1 second, so you have to look for it to notice.

Revision history for this message
ais523 (ais523) wrote :
Revision history for this message
Olivier Tilloy (osomon) wrote :

I am unable to observe the issue in a virtual machine, launching chromium-browser while firefox is running doesn't make it unresponsive.

This sounds like it could be a shortage of memory where your system starts swapping, thus making firefox unresponsive for a while. How much RAM do you have, and do you have swap set up?

Changed in firefox (Ubuntu):
status: New → Incomplete
Revision history for this message
ais523 (ais523) wrote :

I have a total of 8 GB of RAM and 2 GB of swap.

Reproducing the issue with a memory monitor opened, however, showed that the issue was not related to memory exhaustion: I had at least 2 GB of unused RAM at all times, and although the swap was enabled, it was not used (the swap usage remained at 0 throughout the entire period).

Also observed during this test: eight Firefox processes (seven Web Content and one WebExtensions) were running at 50% CPU usage each throughout the time of nonresponsiveness (my computer has 4 cores, so between them they were using up the entire CPU usage of the computer).

Changed in firefox (Ubuntu):
status: Incomplete → New
Revision history for this message
Olivier Tilloy (osomon) wrote :
Changed in firefox (Ubuntu):
status: New → Confirmed
Revision history for this message
ais523 (ais523) wrote :

I can confirm that the bug described in the askubuntu.com link above is the bug I'm seeing; the workaround stated there (renaming `~/.fonts`) was enough to prevent it occurring.

I have fontconfig 2.12.6-0ubuntu2 installed (and my fontconfig-config is the same version).

Should this bug report be moved to the fontconfig package, as apparently it's the underlying cause of the bug? Presumably it will be fixed if/when Ubuntu updates to a newer version of fontconfig.

Changed in firefox:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
In , Release-mgmt-account-bot (release-mgmt-account-bot) wrote :

[Bugbug](https://github.com/mozilla/bugbug/) thinks this bug should belong to this component, but please revert this change in case of error.

Revision history for this message
In , Rjesup (rjesup) wrote :

Jonathan - any ideas here?

Revision history for this message
In , Jfkthame (jfkthame) wrote :

This sounds like it's the same issue as described in bug 1495900. A patch just landed there which we hope will help for people who have affected fontconfig versions.

*** This bug has been marked as a duplicate of bug 1495900 ***

Changed in firefox:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.