Open Bug 1697361 Opened 9 months ago Updated 9 days ago

OOM on


(Core :: Graphics: WebRender, defect)

Firefox 88



Tracking Status
firefox86 --- affected
firefox87 --- affected
firefox88 --- affected


(Reporter: weilercdale, Unassigned)


(Blocks 2 open bugs)



(2 files)

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

Steps to reproduce:

Go to

Click the first link, roll around with the ball for a few seconds.

Actual results:

Continuously allocates memory until there is no memory left to allocate

OOM killer on Linux then reaps the process

[5802499.300219] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-0.slice/session-5.scope,task=firefox,pid=3505672,uid=0
[5802499.300450] Out of memory: Killed process 3505672 (firefox) total-vm:28082936kB, anon-rss:20045372kB, file-rss:29080kB, shmem-rss:30492kB, UID:0 pgtables:41340kB oom_score_adj:0
[5802499.917153] oom_reaper: reaped process 3505672 (firefox), now anon-rss:0kB, file-rss:32292kB, shmem-rss:30012kB

Expected results:

Not allocate so much memory non-stop.

Continuously allocates memory until there is no memory left to allocate

Where to see that? What are exact steps to see that continuous increase?

Which exact Firefox version is this about?

Flags: needinfo?(weilercdale)

This appears to happen in all versions of Firefox I tried, from 84 forward, including Nightly.

Click on the first link on here "Drag this link to your bookmarks bar: [Katamari!]", a message box comes up asking you how to configure it, just click "Start". A pink ball will show up on the page, just hold right click on your mouse to have it roll around the page collecting text elements into a Katamari ball. Doing this for 30 seconds or so the memory usage of Firefox sky rockets. At some point the browser comes unresponsive and then OOM killer on Linux kills it. On a non Linux OS (e.g Windows) it would just stall the system.

Flags: needinfo?(weilercdale)

I was able to reproduce this issue following the steps in comment 2 on latest Nightly version 88.0a1 - Build ID 2021031109300 - User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0 on Ubuntu 20.04 .
Also was reproducible on Beta 87.0b8 - Build ID 20210309185944 - User Agent Mozilla/5.0 (X11; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
and Firefox Release 86.0.1 - Build ID 20210310152336 - User Agent Mozilla/5.0 (X11; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0
Unfortunately in all cases, builds and Ubuntu 20.04 OS stopped working and I had to restart the laptop.
I'll attach file evidence and I'll change components and flags accordingly. Please feel free to change it if this is not the right component.
Severity suggested S2

Severity: -- → S2
Has STR: --- → yes
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64

Hi, do you happen to have the firefox profiler and can capture a profile of this? That would help to verify the component assignment pretty much.

Flags: needinfo?(marcela.calderon)

Hi Jeans!
It is quite difficult to be able to catch the firefox profiler before the laptop crashes but I was able to get one. Please see if it works for you, if not I will try again.

Flags: needinfo?(marcela.calderon)

Not sure about what I see there but there seem to be some activity related to graphics right before the memory starts to increase insanely.

Component: DOM: Core & HTML → Graphics

User reports that it happens in WebRender, but not if he turns WebRender off. Looking at the profile in comment 7, when memory usage spikes, we spend a lot of time inside update_texture_cache, so there might be some suspicious churn going on there.

Component: Graphics → Graphics: WebRender
OS: Linux → All
Hardware: x86_64 → All
You need to log in before you can comment on or make changes to this bug.