Closed Bug 1499385 Opened 6 years ago Closed 6 years ago

Firefox's "Web Content" processes hits 100% CPU usage when Google Chrome is running

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
62 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1495900

People

(Reporter: jerome.auge, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Steps to reproduce: - On Xubuntu 16.04 amd64 - Launch Firefox (62.0.3, Nightly or Developer Edition) - Open websites in tabs - Launch Google Chrome or Chromium (with no tabs) Actual results: - Firefox tabs becomes unresponsive: page does not scrolls and sometimes the page is white with a grey throbber spinning. - System Monitor app shows that a dozen "Web Content" processes are competing for CPU (each processes uses ~8%) and the global CPU usage is at 100% (only with "Web Content" processes). It looks like "Web Content" processes are blocked/frozen by something used or done by Google Chrome... Quitting Google Chrome does not immediately stops the 100% CPU usage of the Firefox's "Web Content" processes. I need to wait almost 1 minute for the activity to return to normal and the tabs to become responsive again. Expected results: - Firefox's tabs should not go unresponsive and "Web Content" processes should not hit at 100% CPU usage.
`perf top` on a "Web Content" process seems to indicate that it is libfreetype which is eating all the CPU? --8<-- 91.02% libfreetype.so.6.12.1 [.] 0x000000000003ba6a 4.79% libfreetype.so.6.12.1 [.] 0x0000000000039425 4.19% libc-2.23.so [.] __memset_avx2 0.00% libfreetype.so.6.12.1 [.] 0x000000000003ba41 0.00% libfreetype.so.6.12.1 [.] 0x000000000003ad85 0.00% libfreetype.so.6.12.1 [.] 0x000000000003b9e0 0.00% libfreetype.so.6.12.1 [.] 0x0000000000033e2f 0.00% libfreetype.so.6.12.1 [.] 0x0000000000036692 0.00% libfreetype.so.6.12.1 [.] 0x000000000003ab07 0.00% libfreetype.so.6.12.1 [.] 0x0000000000034680 0.00% libfreetype.so.6.12.1 [.] 0x000000000003accf 0.00% libfreetype.so.6.12.1 [.] 0x00000000000395ae 0.00% libfreetype.so.6.12.1 [.] 0x0000000000036828 0.00% libfreetype.so.6.12.1 [.] 0x000000000003b250 0.00% libfreetype.so.6.12.1 [.] 0x000000000003b6c6 0.00% libfreetype.so.6.12.1 [.] 0x0000000000037837 0.00% [kernel] [k] perf_event_context_sched_in 0.00% [kernel] [k] native_apic_mem_write 0.00% [kernel] [k] native_write_msr_safe -->8--
Running `strace` on a "Web Content" process seems to indicate that the process is doing repating sendmsg() syscalls with a string containing "/usr/share/fonts/opentype/noto/N". The fonts in "/usr/share/fonts/opentype/noto" directory are "NotoSans-CJK-*.ttc" files provided by the "fonts-noto-cjk" package. Removing the "fonts-noto-cjk" package seems to reduce the Firefox "freeze" effect, in that launching Google Chrome still triggers the "Web content" processes but with less CPU usage. Launching Google Chrome while stracing a "Web content" process, I still see a lot of ssendmsg() syscalls related to fonts. It looks like that the launch of Google Chrome triggers a reload of all the fonts by the Firefox's "Web Content" processes, with the processing of NotoSans-CJK taking a lot of time.
As an initial triage, (Core) Widget:gtk seems a good component to start from. @Jerome: Can you please capture a performance profile? Please download Firefox Nightly from here: https://nightly.mozilla.org/, retest and if the issue also occurs here, record a performance profile. These steps will help you through the process: 1. Install this (https://perf-html.io/) add-on on the Nightly browser. 2. Click on the add-on button from the top right of the page (Geeko Profiler) and click the "Start" button. 3. Reproduce the issue; (Some visible memory/network usage issues should be of great help). 4. Click on the add-on button from the top right of the page (Geeko Profiler) and click the "Capture profile" button. 5. A new page will be displayed (with the actual performance profile), but now you have to share it: Tap on the "Share..." button from the top-right corner of the page, then again "Share' on the pop-up displayed and copy the link back here.
Component: Untriaged → Widget: Gtk
Flags: needinfo?(jerome.auge)
Product: Firefox → Core
Here is the perf profile with FF nightly, a blank profile and just the default "New tab" tab opened (no website loaded): https://perfht.ml/2OC5WBH
Flags: needinfo?(jerome.auge)
I can confirm that I can (partially) see the same symptoms. After opening FF63 on Ubuntu 18.04 with just a "new tab", and then opening Chromium with just a "new tab" the FF WebContent processes max out at 100% CPU for a short time. Maybe about 10s, they then recover. I also reported this issue, which might be related: https://bugzilla.mozilla.org/show_bug.cgi?id=1505416
Mike, can you please take a look over the performance profile from comment 4? Thanks
Flags: needinfo?(mconley)
I'm experiencing the same issue as oliver in the closed 1505416. Locked up tabs after the FF63 update. About 22 tabs open. When one tab becomes unresponsive, I can often find another once responsive tab unresponsive with the grey spinner. CPU @ 100% for firefox-bin -contentproc. Memory usage also increases once tabs start becoming unresponsive. I don't have Chrome/Chromium running. Running xfce Manjaro Linux apophis 4.19.1-1-MANJARO #1 SMP PREEMPT Sun Nov 4 16:05:34 UTC 2018 x86_64 GNU/Linux NVIDIA 410.73 See below perf profile started After my first tab became unresponsive. But before finding other tabs unresponsive. https://perfht.ml/2PqVopc
I also observe from time to time 100% CPU usage on tabs with, I think, a lot of JS or frames content like: Gmail, Tweetdeck, Newsblur. This happens both on Linux and on macOS, with a lot of opened tabs, and a perf trace also shows a high CPU usage on the PollWrapper()/poll() functions (as in the perf trace uploaded by kurssk above). When I notice that my fan is spinning for a long time, I check the `top` output and kill the "Web Content" process that is hitting the CPU which triggers a tab (most of the time one associated with either Gmail, Twweetdeck or Newsblur) to display a failure page and a button to restore the tab. However, I think this might be a separate bug 1505416 (high CPU usage on PollWrapper()/poll()) while bug 1499385 seems more related to libfreetype parsing/reindexing all the fonts.
The profile in comment 4 is showing the content processes taking a long time initializing fonts. Hey jfkthame, do you think this is a dupe of bug 1495900?
Flags: needinfo?(mconley) → needinfo?(jfkthame)
The original report here certainly looks like bug 1495900 (and so updating to a newer version of fontconfig would probably mitigate this, at least to some extent). OTOH, comment 8 looks like a different issue; I don't see the font-scanning issue in that profile, but looking at Content Process 10/10 there, it seems like there may be a GL-related problem: it's stuck in nVidia driver libs, AFAICS.
Flags: needinfo?(jfkthame)
Alright, thanks jfkthame. Let's try to avoid mixing issues here - it sounds like the original report is a dupe of bug 1495900. kurssk, if you're still seeing your issue, would you mind please filing a new bug and posting your profile there?
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Mike if this is not a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=1505416 after all, then can we not resurrect that one? Issue still active for me as well

Waking up an old thread.

For the last couple of days, Firefox on my laptop too has started consuming too much RAM.
Firefox is running continuously on my laptop from 9am to about 1am the following day. Last night around 1 am, I noticed that my Firefox froze and no window was responding. Seconds later, my laptop froze I was getting bare minimal response. After opening the process monitor, I found that a web-content process of Firefox was consuming 5GBs of my 8GB ram! I killed the process and restarted Firefox and things became normal.

Some time later, I again noticed that a web-content process of Firefox was consuming 1GB of RAM and the consumption was rising very fast. In about half a minute, that increased to 2.3GB!

What could be the bug and how can I fix it?

Yatn

I'm also experiencing this problem just like byatin2005. I will try looking up how to run "strace" next time this happens.

Oh, I should mention: list of my addons is Better Tweetdeck, BFA (Better FurAffinity), Checkmarks, Download All Images, Enhancer for YouTube, Facebook Container, FurAffinity Extender, HTTPS Everywhere, Image Search Options, Imagus, Limit Tabs, Twitter Container and Reimagined Twitter, Terms of Service Didn't Read, uBlock Origin, User Agent Switcher, Video Download Helper, View Image, View Image Resurrected and WebP Image Converter.
I'm running Firefox 87.0 64bit on Ubuntu 20.04.2 LTS, also 64 bit.
Also this seems to mostly happen on Twitter, I tried disabling Twitter related extensions (container and reimagined) and we will see if it will still occur.

Also I have no way to know if this happens on Nightly because to be blunt, I never managed to succesfully compile a program from source.

(In reply to nobody.shinobi from comment #16)

I'm also experiencing this problem just like byatin2005. I will try looking up how to run "strace" next time this happens.

Same problem for me running FF89.0 over Ubuntu Mate 20.04.02 LTS (Focal Fossa), kernel 5.4.0-74-generic x86_64 on my brand new laptop with i5 10th gen. The same: with few FF tabs web content was draining all my CPU blood. When not freezing, a plain kill of web content or firefox solved the problem until re-opening of few tabs.

Accordingly with the observation of @Jerome.auge I try to solve it by simply removing that NOTO fonts. And IT WORKED!
I've installed font-manager, searched NOTO, ticks from all noto fonts and sizes removed and voila...
I've tested the system allowing everything in popblocker, and opening many FF tabs, tabs with heavy scripts, simultaneously with chrome, with gmail, etc., and resist everything.
I'm not programmer so, please try and report if it works for you, but seems to that this SOLVES the issue.
Credits for @jerome.auge

You need to log in before you can comment on or make changes to this bug.