Firefox Freezes And Starts Using All Of Available Memory

Ask Fedora
1

Hi,

I’ve been having an issue with the native Firefox on two installs for a few months now since updates - one laptop with Ultramarine 43 KDE and one PC with Fedora 43 KDE - So I don’t think it’s a distribution problem.

The issue is Firefox will be behaving normally (using just under 3GB with current open tabs). Normally the system RAM will be sitting under 50%. Then for no reason after a time - freeze and become unresponsive while the memory usage slowly ramps up to 90-95% (around 10-12GB on a 16GB). If I’m quick enough, sometimes I can kill Firefox myself before it makes the whole system unresponsive. If the system runs out of memory, KDE might kill Firefox itself after about 5-10min. Depending on how much memory is used, sometimes Firefox will recover itself after a few minutes and start working again. But it will keep happening until Firefox is restarted again.

It seems to happen more when the PC is left idle for a bit and you come back to it (so it could be the screen saver has been activated and the monitor would have turned off). I suspect the system might be pushing tabs to SWAP space (or reading from it)

Restarting Firefox seems to temporarily fix the issue for a time, but invariably comes back again. I’ve tried disabling all of the plugins I’m using (which doesn’t seem to make a difference either).

I’ve seen Bug reports for this very issue, but apparently it was fixed in previous updates?

Other than trying to uninstall and reinstalling Firefox, anything else I should be trying? Or is this just a bug that should be reported?

Here’s the info of the laptop:

Operating System: Ultramarine Linux 43
KDE Plasma Version: 6.7.3
KDE Frameworks Version: 6.28.0
Qt Version: 6.10.3
Kernel Version: 7.1.5-100.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 22 × Intel® Core™ Ultra 7 155H
Memory: 16 GiB of RAM (15.0 GiB usable)
Graphics Processor: Intel® Arc
Manufacturer: LENOVO
Product Name: 83DJ
System Version: Yoga 7 2-in-1 14IML9

Firefox version

153.0 (64-bit)

The PC has the same versions, only the amount of RAM and CPU differ.

Thanks

2

There are reports that the systemd-ooom.service is not enabled on some f43 systems.

Make sure that the systemd-oom service is enabled and running then it should kill firefox for you.

systemctl status systemd-ooom.service

If it not enabled and running:

sudo systemctl enable --now systemd-ooom.service

When the problem happens it will be worthy checking in the user and system journals for errors that may give a clue to the issue.

Usually when a web browsers memory use grows it’s triggered by the web sites you are visiting. Keep track of the sites you visit and see if the problem correlates with a particular site or set of sites.

3

That command gave me

Unit systemd-ooom.service could not be found.

Did you perhaps mean
systemd-oomd.service by any chance?

The output of systemctl status systemd-oomd.service was

○ systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer
     Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.service; disabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)
TriggeredBy: ○ systemd-oomd.socket
       Docs: man:systemd-oomd.service(8)
             man:org.freedesktop.oom1(5)

I changed that to sudo systemctl enable --now systemd-oomd.service which gave an output of

systemctl status systemd-oomd.service           
● systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer
     Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Wed 2026-07-29 07:30:42 AEST; 6s ago
 Invocation: 03b100d38de5444c9dc37016d7097faa
TriggeredBy: ● systemd-oomd.socket
       Docs: man:systemd-oomd.service(8)
             man:org.freedesktop.oom1(5)
   Main PID: 9629 (systemd-oomd)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18386)
     Memory: 1.8M (min: 64M, low: 64M, peak: 3.7M)
        CPU: 26ms
     CGroup: /system.slice/systemd-oomd.service
             └─9629 /usr/lib/systemd/systemd-oomd

Jul 29 07:30:42 Lenovo-Yoga-UM-KDE systemd[1]: Starting systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer...

Will this be persistent after a reboot? Or would I need to add it somewhere?

This might stop the whole OS crashing, but not really why Firefox is doing it in the first place.

I’d sort of thought about that, but the two PCs have different tabs open and the problem only seemed to start happening after an update a few months back.

I’ll have a look at the logs next time it’s happening. As I said, seems to do it for no apparent reason as it’s currently behaving at present.

4

Next time it happens, hit Shift+Esc within Firefox and see if any specific tab is the cause of the memory consumption.

5

Appologies; I stared at the that spelling and could not see the error…
(was not able to copy-n-paste…)

6

Will do. I had a quick try and yep, brings up all of the current processes for the tabs which will be handy. Maybe there’s a certain tab that’s not being loaded after the restart and only starts after a certain amount of time?

7

The problem disappeared again for a while but has now come back again. I opened both KDE System Monitor, HTOP and the Firefox process tab with “shift=esc”.

Unfortunately I couldn’t really narrow it down to one misbehaving tab or process. But its definitely one of the Firefox processes and possibly a Youtube tab. And the processes that System Monitor and HTOP showed where two different PIDs.

There’s a lot of other tabs and windows open - 10 Windows (with multiple tabs in each. One Window has 9 Youtube tabs. 4 actively loaded, 5 weren’t open and inactive (from the last restart of Firefox). These were using the most memory.

What I observed with the system monitors was

  • current active tab (with Youtube) sat around 400-500mb
  • Total memory used by firefox was sitting around 1000mb
  • Total system memory usage was about 50% (8GB).

Whenever there was a CPU spike (about 15-20%), the memory would also climb to 70-80% for a short time with video playback also stuttering for a second. Then return back to 50% memory.

I watched 3 of the videos on the active (open) tabs for an hour and the memory CPU continued to spike maybe every 10sec. I closed the tab when I was finished watching. When I got to the 4th active YT tab and started watching that, I switched to a completely different window and did some other work (while watching YT in the background). The problem mysteriously went away again. And still stayed away when I went back to that Window.

Currently

  • Firefox is sitting at 850mb total
  • current tab using 450mb
  • system is at 6.5gb with no spikes from the YT tabs

It’s possible that closing one those tabs was the issue. But it was still doing it when I started to play the video in the 4th (last active) tab. I haven’t had the issue on the other computer since restarting, bookmarking all of the open tabs and closing them.

I really don’t know where to go from here?

8

You could try having sudo memstrack running in a window if you’re not entirely sure it’s a problem within Firefox with a specific tab.

It’ll show you every process, it’s current memory allocation, and it’s peak memory alloc:

q': quit, 'r': reload symbols, 'm': switch processes/modules, 'p': pause UI
Pages being tracked: 14980 (58MB)
┌   PID   |    Pages   |    Peak    |   Process Command Line
│    2396 |       1340 |       6841 | /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_sYDlPp --xwayland                                                          │
│  105808 |       4761 |      14597 | /app/zen/zen --name app.zen_browser.zen                                                                                                                                                                                             │
│  106050 |       2921 |       4315 | /app/zen/zen -contentproc -isForBrowser -prefsHandle 0:36410 -prefMapHandle 1:299959 -jsInitHandle 2:156236 -parentBuildID 20260729085236 -sandboxReporter 3 -ipcHandle 4 -initialChannelId {3b8ff5b2-ad36-4926-bee5-dba93d521797}  │
│  106109 |       1472 |       1748 | /app/zen/zen -contentproc -isForBrowser -prefsHandle 0:44463 -prefMapHandle 1:299959 -jsInitHandle 2:156236 -parentBuildID 20260729085236 -sandboxReporter 3 -ipcHandle 4 -initialChannelId {fc247109-b683-4ba7-bade-7d19d711a1b1}  │
│  106330 |       1334 |       6216 | /app/zen/zen --name app.zen_browser.zen                                                                                                                                                                                             │
│  106068 |        782 |       1134 | /app/zen/zen -contentproc -isForBrowser -prefsHandle 0:36410 -prefMapHandle 1:299959 -jsInitHandle 2:156236 -parentBuildID 20260729085236 -sandboxReporter 3 -ipcHandle 4 -initialChannelId {3b8ff5b2-ad36-4926-bee5-dba93d521797}  │
│  105905 |        513 |        514 | /app/zen/zen --name app.zen_browser.zen                                                                                                                                                                                             │
│    2627 |        360 |        426 | /usr/bin/plasmashell --no-respawn                                                                                                                                                                                                   │
│  105942 |        221 |        398 | /app/zen/zen --name app.zen_browser.zen                                                                                                                                                                                             │
│  106127 |        227 |       1494 | /app/zen/zen -contentproc -isForBrowser -prefsHandle 0:44463 -prefMapHandle 1:299959 -jsInitHandle 2:156236 -parentBuildID 20260729085236 -sandboxReporter 3 -ipcHandle 4 -initialChannelId {fc247109-b683-4ba7-bade-7d19d711a1b1}  │
9

Thanks Steve,
I’ll give that a go when it happens next time.
Cheers