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

Steps to reproduce:

Start firefox, use it for a bit

Actual results:

Firefox is consuming almost all of the RAM on my system, to the point my swap space is also filling up. Checking about:processes reveals that "Data Decoder" is using 8GB of ram

Expected results:

This did not occur before. I believe it is happening ever since I updated Firefox

I'm guessing that "Data Decoder" means the RDD process.

Could you please attach an about:memory report from while this is happening? Hopefully before it is taking up all of the memory, because getting a report can use up some resources so you want to do it before that. Also, feel free to check the "anonymize" box or it'll include the URLs of your open tabs.

(In reply to Andrew McCreight [:mccr8] from comment #1)

I'm guessing that "Data Decoder" means the RDD process.

Could you please attach an about:memory report from while this is happening? Hopefully before it is taking up all of the memory, because getting a report can use up some resources so you want to do it before that. Also, feel free to check the "anonymize" box or it'll include the URLs of your open tabs.

Hi, I have attached the memory report. For some more information, it seems to be related to video somehow. If I open Youtube Shorts and scroll down to the next video, my system memory usage increases by about 3% each time I scroll down. But then closing the Youtube Shorts tab still keeps the memory usage around the same, even if I go to about:memory and press the minimize memory usage button. Closing just about every tab (except this one) brings down total memory use by about 7%, which means Firefox is still using about 6GB of memory.

This bug was moved into the Performance component.

:kamalahmad22, could you make sure the following information is on this bug?

• For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• ✅ For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Thanks for the memory report. As expected, this is in the RDD process. Unfortunately, it is all under heap-unclassified. I think the next steps here are to look at a profile and hope that something shows up, or if somebody can reproduce in a DMD build we can see where the memory is going at least.

The RDD process is used by every web page, so I think it is expected that if there's a leak that just closing the tabs won't fix it.

I'll move this to A/V playback, given that the steps involve YouTube and I expect that RDD is being use for video decoding somehow.

Also, if you could more specific about what the steps to reproduce are and maybe attach your about:support that could help.

I was unable to reproduce this on Firefox 116 on MacOS. I went to a specific YouTube Short video, then scrolled down to the next video, then did that over and over again, sometimes letting the video play a bit and sometimes just scrolling as fast as I could, and my RDD process memory didn't go above 6MB. I could certainly imagine there are OS-specific differences. It looks like the reporter is on Linux.

(In reply to Andrew McCreight [:mccr8] from comment #6)

Also, if you could more specific about what the steps to reproduce are and maybe attach your about:support that could help.

I was unable to reproduce this on Firefox 116 on MacOS. I went to a specific YouTube Short video, then scrolled down to the next video, then did that over and over again, sometimes letting the video play a bit and sometimes just scrolling as fast as I could, and my RDD process memory didn't go above 6MB. I could certainly imagine there are OS-specific differences. It looks like the reporter is on Linux.

Hi, upon further inspection it seems to be related to VAAPI (hardware video acceleration for Linux). Disabling VAAPI by setting media.ffmpeg.vaapi.enabled to false seems to prevent memory from being leaked.

I have attached about:support information.

Per comment7, link this to VAAPI meta bug.

Does this problem still occur after setting media.ffmpeg.vaapi.force-surface-zero-copy to 1 on about:config and restarting Firefox?

(In reply to Darkspirit from comment #10)

Does this problem still occur after setting media.ffmpeg.vaapi.force-surface-zero-copy to 1 on about:config and restarting Firefox?

Yes, it's still occurring. I have attached the output of vainfo -a incase it helps.

Your vainfo doesn't contain any useful codecs. Fedora's ffmpeg and mesa-va-drivers packages have patented h264 disabled by default.
Users can replace those packages with ones from a third party repository: https://rpmfusion.org/Howto/Multimedia

109: Since bug 1756459, HW codecs found by VAAPI test are listed on about:support.
114: Since bug 1787182, VAAPI codecs are only tested&reported if HW decoding is enabled.
115: Since bug 1831038, VAAPI won't be used for a codec if it's not listed as HW codec on about:support. In case this bug only occurs if the VAAPI driver doesn't support any relevant codec, that change would prevent this bug.

(In reply to Darkspirit from comment #13)

Your vainfo doesn't contain any useful codecs. Fedora's ffmpeg and mesa-va-drivers packages have patented h264 disabled by default.
Users can replace those packages with ones from a third party repository: https://rpmfusion.org/Howto/Multimedia

109: Since bug 1756459, HW codecs found by VAAPI test are listed on about:support.
114: Since bug 1787182, VAAPI codecs are only tested&reported if HW decoding is enabled.
115: Since bug 1831038, VAAPI won't be used for a codec if it's not listed as HW codec on about:support. In case this bug only occurs if the VAAPI driver doesn't support any relevant codec, that change would prevent this bug.

Hi, good catch! The last time I checked vainfo it had H264/H265 but it doesn't anymore, as Fedora removed them by default. Replacing the VAAPI drivers with the freeworld drivers (proprietary codecs included) on Fedora seems to fix the issue. So I guess the bug only occurs if the decoder doesn't find a suitable hardware codec? But strangely, by forcing Youtube to use AV1 which my GPU doesn't support doesn't cause this memory leak issue in the same case (scrolling through Youtube Shorts).

The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Configuration: Rare
[x] Causes severe resource usage

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

From the report it looks like a problem with Fedora ffmpeg/OpenH264 backend (Fedora ships openh264 as ffmpeg decoder now).
On setup where you see the bug, can you please run Firefox as:

MOZ_LOG="PlatformDecoderModule:5" firefox > log.txt 2>&1

and attach the log here?
Thanks.

I have att(In reply to Martin Stránský [:stransky] (ni? me) from comment #17)

From the report it looks like a problem with Fedora ffmpeg/OpenH264 backend (Fedora ships openh264 as ffmpeg decoder now).
On setup where you see the bug, can you please run Firefox as:

MOZ_LOG="PlatformDecoderModule:5" firefox > log.txt 2>&1

and attach the log here?
Thanks.

I have attached a log with this running (swapped mesa freeworld drivers with regular drivers which don't have h264 and some other codecs) in the case where this occurs most often which is scrolling through Youtube Shorts

Not related to VA-API.