[SOLVED] Firefox tight poll loop (100% CPU).

Hello, everyone.

Some time ago I found that once in a while Firefox misbehaves in a sense that it eats a lot of cpu and becomes unresponsive.

Constraining it into a cgroup made the system more usable. (https://www.linuxquestions.org/questions/slackware-14/[testing-needed]-responsiveness-optimizing-cgroups-rc-script-4175655892/), but didn't make Firefox itself as reliable as it used to be.

So I decided to profile the beast, and first I tried it with a recommended by Mozilla Firefox Profiler http://profiler.firefox.com

It basically showed me that Firefox gets stuck in a tight poll loop, polling for ... what? I didn't see which resource it so desperately wanted. (Perhaps due to the lack of knowledge.)

As a simple solution, I tried to rebuild Firefox parameters different from those provided by the default Slackware, and indeed, after a rebuild, Firefox 60 lost it's tendency to get stuck.

Then the upstream received the newer version 68, and I had to play with parameters a few times again, to find out which combination works for me. It turns out that the following patch to the Slackbuild was needed to get rid of that loop in 68:

diff --git a/source/xap/mozilla-firefox/mozilla-firefox.SlackBuild b/source/xap/mozilla-firefox/mozilla-firefox.SlackBuild
index 363e2cf7..1d75fa0c 100755
--- a/source/xap/mozilla-firefox/mozilla-firefox.SlackBuild
+++ b/source/xap/mozilla-firefox/mozilla-firefox.SlackBuild
@@ -124,7 +124,7 @@ elif [ "$ARCH" = "s390" ]; then
   SLKCFLAGS="-O2"
   LIBDIRSUFFIX=""
 elif [ "$ARCH" = "x86_64" ]; then
-  SLKCFLAGS="-O2 -fPIC"
+  SLKCFLAGS="-O3 -fPIC"
   LIBDIRSUFFIX="64"
 elif [ "$ARCH" = "arm" ]; then
   SLKCFLAGS="-O2 -march=armv4 -mtune=xscale"
@@ -219,13 +219,10 @@ OPTIONS="\
   --enable-default-toolkit=cairo-gtk3 \
   --enable-linker=gold \
   --enable-startup-notification \
-  $GOOGLE_API_KEY \
   --enable-strip \
   --enable-cpp-rtti \
   --enable-accessibility \
   --disable-crashreporter \
-  --disable-debug-symbols \
-  --disable-debug \
   --disable-optimize"
 # Complains about missing APNG support in Slackware's libpng:
 # --with-system-png \
@@ -286,6 +283,7 @@ for option in $OPTIONS; do echo "ac_add_options $option" >> .mozconfig; done
 
 # https://developer.mozilla.org/en-US/docs/Building_with_Profile-Guided_Optimization
 # Thanks to ArchLinux and Gentoo for the additional hints.
+PGO=yes
 if [ "$PGO" = "yes" ]; then
   # Do a PGO build, double time and disk space but worth it.
   export MOZ_PGO=1
@@ -293,7 +291,7 @@ if [ "$PGO" = "yes" ]; then
   export DISPLAY=:99
   # Launch Xvfb to let the profile scripts run in a X session.
   # Ugly note: if the build breaks you may want to do a "killall Xvfb".
-  Xvfb -nolisten tcp -extension GLX -screen 0 1280x1024x24 $DISPLAY &
+  Xvfb -nolisten tcp -extension GLX -screen 0 1366x768x24 $DISPLAY &
   dbus-launch --exit-with-session ./mach build || exit 1
   kill $! || true
 else

I don't know which one of those five changes unbroke my Firefox:

• -O3
• debug info
• PGO
• Degooglification
• Native Xfvb resolution

I am not really asking anything in this topic, just want to leave this information public on the net for someone who may find it if having a similar problem.

It took roughly 10 hours to rebuild Firefox on my machine, which is Dell Latitude E6420,
2-core, 4-hyper-thread, Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 16 Gb RAM.

If the answer is in your build configuration, my guess would be the -O3 as they use that for their official binaries. It's probably the most tested optimization level.

One of the things I did while troubleshooting getting PGO+LTO to work for my Firefox builds (this was Firefox 66.x at the time I jumped on that bandwagon... I just did normal builds before that) was to download and unpack their offical binaries and do about:buildconfig to see what they did.

I build it while running X so I don't need the Xfvb for the profiling step. It launches the client for the profiling tests in the background. (I don't see it because it's always behind my urxvt terminal but one time I did when the terminal was out of focus). That sounds less likely that the virtual resolution would affect your results.

After 2 years of battling the 100% cpu issue with Firefox and trying everything mentioned above, i resorted to what you see below, for fear of tosting my laptop cpu ...


bash-4.3# cat /root/scripts/temp.sh
#!/bin/bash
temp=`sensors | grep C | head -n1 | tr "." " " |awk '{print $4}' | tr -d "+" | tr -d "°C"`
if [ "$temp" -ge "75" ]; then
firekill
firekill
fibash-4.3# cat `which firekill`
killall firefox-bin
killall /home/xxxxxx/opt/firefox/firefox-bin
bash-4.3# crontab -l | grep temp
*/5 * * * * /root/scripts/temp.sh
bash-4.3#

I've had such issues in the past with older releases of firefox (ESR?). If I recall correctly, it disappeared when I removed all add-ons (before adding a smaller set of add-ons again).

Fwiw, I cannot praise the current version of firefox (88.0) enough for a remarkable increase in stability on my machine.