Recently I started to observe this very confusing and annoying, not to say worrying behaviour when having Firefox open and then launching Chromium:

For around 30 seconds, Firefox' child processes would consume all available CPU resources, causing websites to stop render (already displayed page freezes, new pages show a white page with grey spinning circle) while the overall window is still responsive (menus, page scrolling, switching tabs, even internal pages like about:config or about:preferences work...). Chromium itself does not show any symptoms. Terminating Chromium again immediately, while Firefox is spinning, does not stop the behaviour any faster.

The same happens with my regular Firefox profile, a brand new, untouched Firefox profile without any add-ons etc., Firefox started in safe mode with add-ons disabled, and Firefox started in private mode. Similar for Chromium, I can launch it with my regular profile, in incognito mode or with a temporary profile, always generating the same results.

There is nothing odd happening when Chromium is running and I open Firefox.

When launching Firefox from a terminal, I sometimes get messages like these when I quit it while it is spinning (note the pipe error line mentioning some chromium 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

Strangely I could not reproduce that behaviour in a guest account or a newly created regular (admin) account.

Some system specs (updated):

  • Ubuntu 16.04 (64 bit)
  • Firefox 62.0+build2-0ubuntu0.16.04.5 63.0+build2-0ubuntu0.16.04.2
  • Chromium 69.0.3497.81-0ubuntu0.16.04.1 70.0.3538.77-0ubuntu0.16.04.1
  • fontconfig 2.11.94-0ubuntu1.1
  • Graphics hardware: Intel SkyLake integrated graphics (i5-6200U) + Nvidia GeForce 940M
    Currently I have the nvidia-410 driver installed, but switched to the Intel prime profile. How can I further troubleshoot and fix this issue?

I made a performance profile with the Gecko Profiler Extension, installed to a clean fresh Firefox profile on my regular Ubuntu account. It can be found here: https://perfht.ml/2zpTWsh - The unresponsive time frame with 100% CPU usage should roughly correspond to the highlighted area on the Content Proc timelines, from roughly 18s - 56s.

I created a Mozilla bug report for this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1504461

Important update: Apparently my bug report was a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1495900, which points out fontconfig as the culprit. Seems like starting Chromium is making a change in the font configuration somehow, which triggers a complete reload in Firefox. This fits the performance profiling report, and also aligns with how former updates to font packages have triggered the same kind of freeze.

Any ideas how I can make the three (Firefox, Chromium, fontconfig) behave nicely along each other?

  • All I'm finding at line 353 of ipc_channel_posix.cc is a return true statement. Of course Connection rest by peer being fatal never bodes well. Sadly I cannot reproduce this problem. I wish I could be of more help.
    – Elder Geek
    Nov 2, 2018 at 14:45
  • I also had sporadic issues w/ high cpu on ubuntu, but I can't say what caused it, or resolved it. There were numerous open issues that I was tracking related to high cpu usage--so, I'd upgrade, and hope. Currently, I'm not having any issues (or if I do, it's a specific tab; so, restarting the browser or closing the tab resolves it). Is it possible to upgrade from 16.04 to 18.10 (as, of course, 16.04 is from 4/2016 and 18.10 is as of 8/2018)...? And, fwiw, I've also switched to kubuntu which seems to gives me fewer headaches. (If possible, boot from USB & experiment w/ both.)
    – michael
    Nov 3, 2018 at 6:57
  • Sometimes I have Firefox running and then open Chrome (I know it's a little different) and haven't noticed any high CPU usage. Perhaps 5 second spike from 18% CPU to 30% CPU across 8 virtual CPUs. Nov 3, 2018 at 23:31

8 Answers 8


TL;DR: It's an issue with fontconfig before version 2.13. It can be fixed by upgrading the package to 2.13 or higher (though I couldn't find a suitable provider). Alternatively, examine all your fonts-related folders and config files in your home directory and test if removing any of them resolves your issue. For me, renaming ~/.fonts did the trick.

After learning about the bug reports https://bugzilla.mozilla.org/show_bug.cgi?id=1495900 and https://bugzilla.mozilla.org/show_bug.cgi?id=1411338 it becomes rather clear that the problem must be caused by fontconfig.

Somehow when Chromium starts, it triggers a change in the fonts database (???), which causes Firefox - if currently running - to re-scan the file system for fonts somehow, resulting in the CPU usage and temporary freeze.

Apparently updating the fontconfig package from version 2.11 to 2.13 (the version shipped e.g. in Ubuntu 18.10) should fix the issue, but I found no easy way to get that version on 16.04, without breaking dependencies of lots of other packages I have installed.

So as the issue is limited to my user account, I examined my user's local font configuration and folders. There's quite a mess of different font-related directories to be honest, including ~/.fonts, ~/.local/share/fonts, ~/.local/share-font-manager, ~/.config/font-manager, ~/.cache/font-manager, ~/.cache/fontconfig and a few more config files and application-specific font stuff.

I started by removing (renaming) the ~/.fonts folder, as it didn't seem to contain anything useful anyway, and a simple touch ~/.fonts/Library/ before that triggered the Firefox misbehaviour. After that folder was gone, so was the issue when launching Chromium. \o/

  • Makes sense as I have no ~/.fonts directory. All fonts are in a system wide directory. Nov 4, 2018 at 1:02
  • Apparently a similar or even the same bug can be triggered on 18.04 by launching a root terminal window too. strace indicates some serious file i/o regarding font files. Interestingly this is not only a problem with firefox alone but other xorg applications as well so i presume a problem within xorg as well. Unfortunately deleting the directories in question did not help.
    – stefanct
    Dec 7, 2018 at 23:48
  • 1
    However, upgrading fontconfig to 2.13.0-5ubuntu3 from cosmic/18.10 did solve the problem AFAICT. This was the weirdest bug in a while... thanks for the pointers.
    – stefanct
    Dec 8, 2018 at 0:23
  • @stefanct how did you get it to install without breaking stuff, i tried forcing fontconfig and libfontconfig1 2.13 and apt wanted to remove my entire DE, running 18.04 Dec 13, 2018 at 1:57
  • @GM-Script-Writer-62850 I have not any remembrance of dealing with libfontconfig1 specifically. In general I have added the bionic mirrors to apt's list and apply apt pinning to avoid installing any of its packages w/o telling it specifically. Then I simply used apt's -t option like so: apt install fontconfig -tcosmic. I am using mate as DE… maybe it does not work as easily with other DEs.
    – stefanct
    Dec 13, 2018 at 4:05


It has been proposed this Firefox Bug 1492360: High CPU usage when open Firefox before chrome/chromium. That is a duplicate of Bug 1495900: Starting Chrome makes Firefox content processes hang for about two minutes, due to FontConfig font rescanning (FcInitReinitialize), is the culprit.

But I'm on Firefox too:

Firefox version.png

And when I open up Chrome:

Chrome version.png

I don't see any performance hit to CPUs.

It may be against your morals but perhaps you can try installing google-chrome-stable like I have. Then do the test again. If there is no CPU usage spike to 100% then a bug report could be filed between Chromium and Chrome.

I'm on Ubuntu 16.04.5 LTS. Although kernel is currently 4.14.78 LTS chain I don't think that has anything to do with it as I didn't notice CPU hits on previous kernels either.

The only time I see all CPU's at 100% is during update-initramfs.

fontconfig version

In the bug report it is revealed:

$ 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 my non-buggy version (could be because of no local fonts though):

$ 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

I'm at 2.11.94 version earlier than bug report 2.12 version. In bug report upgrading to 2.13 is a recommended solution but OP mentioned in comments this isn't possible. As such 2.11.94 might be an option.

  • Well no, I don't intend to install Chrome. However, I found out that the culprit is fontconfig now. Probably you have different (or no) local fonts installed in your user account. I found a workaround of removing (renaming) the ~/.fonts folder, which fixes the issue. Apparently also upgrading to fontconfig >= version 2.13 should fix it, but I can't do that on 16.04.
    – Byte Commander
    Nov 4, 2018 at 0:30
  • Yes the only fonts I've installed are for bar codes (code 3 of 9) which are ttf and used in word processors / spreadsheets. Unfortunate you had to solve your own bounty question but if it's any consolation the same has happened to me in the past. Nov 4, 2018 at 0:37
  • I added downgrading fontconfig as an option to match my version but that is a "faint hope" given you may have come from there. If you have a link for installing local fonts I'll give that a try to confirm/deny the effect of older fontconfig version. Nov 4, 2018 at 0:47
  • 1
    My version of fontconfig is 2.11.94-0ubuntu1.1 too, that one is not bug-free. It must be a combination of the installed fonts, custom font configuration and black magic, I guess. Check my answer. :)
    – Byte Commander
    Nov 4, 2018 at 0:50

Judging from the log, it looks like Firefox is using synchronous IPC (Inter-process communication) for some reason. There are flags in Firefox to turn on synchronous IPC explicitly (eg: network.cookie.ipc.sync). One of those might be enabled. You can access these from the about:config page

The delay would then be a result of firefox waiting on the response. Since there is no load when Chromium has finished starting up or is not actively running, there is an immediate response.

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

  • I toggled the value of this network.cookie.ipc.sync config from false to true and back, restarting Firefox after each change, but still the same behaviour :( I still don't get why Firefox and Chromium would even communicate in the first place, they should mind their own business each.
    – Byte Commander
    Nov 3, 2018 at 12:34
  • 1
    I had deleted this since you found the actual reason to be unrelated, but I guess I should leave this here as probable cause?
    – Aswin B
    Nov 4, 2018 at 19:36

On Ubuntu 16.04, deleting the empty folder ~/.local/share/fonts solved it in my case.

  • I'm on 19.04 and I think this might have fixed my problem. Jan 17, 2020 at 20:26

Quickest solution

TL;DR? Just cut and paste this command into the terminal:

echo 'user_pref("security.sandbox.content.read_path_whitelist", "/var/cache/fontconfig/,'$HOME'/.cache/fontconfig/");' >> ~/.mozilla/firefox/*.default/user.js

and restart Firefox.


The problem of Firefox freezing when fonts are updated (which was the actual problem, not Chromium), is fixed by telling Firefox to not sandbox access to your font cache directory.

There was a patch for this that supposedly fixed the issue in Firefox 76. However, I'm using Firefox 78.10.0esr and the problem still occurs.

Note that while version 2.13 of fontconfig is much better than earlier versions, this slow down can still be quite painful for users with many fonts installed in $HOME/.local/share/fonts. On my machine which has fontconfig 2.13.1, Firefox had 15 seconds of 100% CPU jank every time I used touch or rm in the fonts directory.

The fix

Edit the file ~/.mozilla/firefox/RANDOM.default/user.js, which may not exist, and add the following javascript:


Note 1: for inscrutable reasons, Mozilla has decided to add RANDOM letters and numbers the name of the default preferences directory. Most people only have one profile and can use *.default to work around that silliness.

Note 2: Replace YOURNAME with your username.


Don't know if the following suggestion will work or not. You can give a try. Try removing chromium and firefox completely (keep the .deb files of course) using Synaptic Package Manager. After that check if there are any broken dependencies. Fix them using synaptic (if any). Now check for the CPU usage (I use Powertop).Finally do a fresh re install of the browsers.

Note: These things are generally what I do in case of specific abnormalities. I remember facing a slightly similar issue a year ago. It got resolved this way.

  • Nope, purging and reinstalling all firefox* and chromium* packages did not change anything.
    – Byte Commander
    Nov 3, 2018 at 17:23
  • does the idle stats and frequency stats widgets of powertop show 100% usage when you launch chromium ?
    – creative
    Nov 3, 2018 at 17:40
  • Yes, it shows around 112% for "C0 active" on every core in idle stats, and frequency stats report the maximum frequency (2.7GHz) and 0% idle on each core. The overview tab displays all the Firefox processes on top of the list, with roughly 600-900ms/s computing time each, but zero events/s.
    – Byte Commander
    Nov 3, 2018 at 17:48

I have a large amount of fonts and this issue was regularly making Firefox unusable for at least fifteen minutes (never waited long enough to know if it would ever end). I've had the problem ever since I upgraded to Bionic (18.04). In my case, it would reliably trigger if I installed or removed a font from ~/.fonts, but anything that causes a fc-cache run would trigger the problem.

I have updated all fontconfig related packages to newer versions from cosmic (warning: totally unsupported by Ubuntu!). Firefox now recovers from touch ~/.local/share/fonts in seconds. I am now running fontconfig 2.13.0-5ubuntu3. I've tested Firefox, OpenOffice, GIMP and a few other tools without encountering any issues so far, but caveat emptor.

Disclaimer: this is totally unsupported, and among other things means that Ubuntu can't fix security issues in fontconfig for you.


Similar problems here with Mozilla Firefox consuming high CPU and heating up the chip and freezing the screen. The simple solution is to start firefox from a terminal with the following command

$ nice -n 1 firefox &

Then open in another terminal HTOP and increase the 'nice' value of the main firefox process to a higher number 1-19, worked out fine for my old nano 32bit OS, no more overheating and/or freezing, everything runs smoothly now.

Upgrade: Since the upgrade to Firefox 104.0.2 (32-bit) it uses a huge amount of CPU and heats up the processor to 90°C.

Solution - Open a terminal and enter the following commands

sudo renice -n x -u username (x=1-19) 

htop and search for firefox PID 

sudo cpulimit --pid xxxx --limit 80 --background 

Is the only working interim solution for me and my old 32-bit OS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .