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

Steps to reproduce:

set background-image: -moz-element(#background); and update
#background

See html attached.

Actual results:

Huge and fast memory leak.

Hi, I was able to reproduce this issue on a Windows 10 machine with 16GB of ram, the moment I load the attached file into Firefox the CPU goes to 100% in an instant.

Im not sure if the Dom: Core & HTML is the correct component for this issue but please change it to a more suitable component if its not the right one.

Since the CPU goes to 100% using the reduced case I think the severity for this issue should be an S3 or even an S2, I'm not sure how much this impacts our users experience.

I'm on debian sid. It doesn't load CPU much (IIRC), but OOM kills it less than in a minute as it eats all my 32Gb RAM.

Pinging Emilio as this is CSS related.

In fact it load all 8 HT cores to 100%

I took a look with DMD, and most of the memory is in WR blobs...

Sergio, can you attach your about:support?

So, here's what I see: https://share.firefox.dev/3ipVyHd

With WebRender (on my machine at least) there's no leak. I took a look on a debug build, and at least from what I see the layout / canvas data-structures are not being leaked (I also took a DMD run up there). I took another DMD run much later and it was similar, there was no significant memory growth. Most of the unreported memory comes from WebRender's blob code (not too unsurprising). Maybe we could report that memory better.

The experience is pretty terrible, though looking at the test-case again it is not very surprising (it's pushing a giant blob as a background-image over and over). It might be that my machine is very fast and can keep up, but I could imagine that on a slower machine we'd just send blobs over to the parent continuously eventually running out of memory.

There's a bunch of busy WrWorker threads just doing memmove replaying the canvas commands... There's also compositor stalls of half a second under mozilla::wr::ShmSegmentsReader::ReadLarge.

Jeff, Nical, maybe some of that could be improved? Maybe you can repro leaks?

I think for -moz-element(canvas) right now we're taking a snapshot but maybe we can just take the recording in this case?

Sergio, a profile would also be extremely useful, that can also track memory usage over time so it might be interesting and provide some insight.

Given the investigation and profiles (I don't know if sergio is using WebRender or not), I think it's safe to move this to Graphics for now.

WebRender is manually enabled in about:config, but I can't reproduce this more, looks like due to 81 version.

I even can't reproduce this with the same previous firefox 80.0 and 80.0.1 from snapshot.debian.org.
Perhaps it was related to the radeon driver, that I replaced with amdgpu, with video card upgrade.

I got a crash after opening the testcase for about 1-2 minutes:
https://crash-stats.mozilla.org/report/index/c4876c10-7b4c-4110-9cc2-0d2020201006

Bug 1630774 seems to track that crash. This was initially about a memory leak, best not to mix things in a single report.