1952340 - Potential memory leak on GPU process after playing video on Firefox Windows

Status: NEW

(Core :: Graphics, defect)

Description

[Alastor Wu [:alwu]]

While working on bug 1942097, I observed that GPU memory usage during video playback seems unusually high. Even after the video is stopped or destroyed, the memory doesn't seem to be released properly sometimes.

Here’s an easy way to reproduce the issue:

STR.

1. Open about:processes and monitor the GPU process memory usage.
2. Open a new tab and navigate to: https://paul.cx/public/test-videos/pattern-1280x720-libvpx-vp9-yuv420p.mp4.
3. Continuously refresh the video tab. Each time you refresh, you’ll notice that the memory usage of the GPU process increases.
4. Once you observe a significant increase in GPU memory usage, close the video tab and continue monitoring the memory usage.

Expected.
5. The memory usage should return to the same level it was at before the video started playing.

Actual.
5. The memory usage remains higher than before the video started playing.

---

While this issue may not be as apparent when playing the above file, it is more noticeable on YouTube. To observe it more clearly, just keep playing different YouTube videos and watch the GPU memory usage. Each new video significantly increases memory usage.

This issue can be reproduced on both Intel and Nivida card, but it seems worse when I select Intel card as default for Nightly.

Sotaro, do you have any insights into this issue? I suspect there might be a cleanup issue on the gfx side. Would you be able to help investigate further? Thanks!

Comment 1

[sporocyst.tw]

Same here. In the latest nightly, the rise of vRAM mentioned in bug 1942097 is much slower but still exists. (sorry, I can't directly respond there since it is a closed bug). bug 1847453 is probably also related.

Comment 2

[Alastor Wu [:alwu]]

Oops, Just realized I forgot to set the NI.

Comment 3

[causeless]

I have encountered a similar issue. In my case, with Firefox 137.0.2, setting gfx.canvas.accelerated to false resolved the GPU memory increase.

Comment 4

[Mayank Bansal]

(In reply to causeless from comment #3)

I have encountered a similar issue. In my case, with Firefox 137.0.2, setting gfx.canvas.accelerated to false resolved the GPU memory increase.
Could you file a new bug with exact steps to reproduce, a testcase and details of about:support? Setting gfx.canvas.accelerated to false is not something we want users to have to do.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the following bug duplicate has higher severity:

• Bug 1962210: S2

:jimm, could you consider increasing the severity of this bug to S2?

For more information, please visit BugBot documentation.

Comment 7

[Ashley Hale [:ahale]]

I'm pretty sure this is the same memory leak we've seen with leaked decoder devices and associated buffers.

Comment 8

[Alastor Wu [:alwu]]

Ashley, do you have any thought about where those leaked devices are? and how to fix that? Thanks!

---

Considering this issue seems getting more common to be reproduced by users, and we even saw ~360GB allocated in the GPU process (see this), we should raise it to S2.

Comment 9

[Ashley Hale [:ahale]]

I concur with this being S2, but I don't have knowledge on the video decode device system, Sotaro would know more about that.

Comment 10

[Sotaro Ikeda [:sotaro]]

Attachment: temporal patch Add logs around hardware video decoder's count

Comment 11

[Sotaro Ikeda [:sotaro]]

I tested several Win PCs with Attachment #9490240 [details] [diff].

The problem with some PCs and did not happen others like the following.

• The problem happened: Win11 with Intel GPU. Win11 with AMD GPU.
• The problem did not happen: Win11 with NVIDIA GPU. Win10 PC with Intel GPU

From the log, the problem happened even when the followings were zero and memory was minimized from about:memory.

• D3D11TextureData
• DXGITextureHostD3D11
• WMFVideoMFTManager
• FFmpegVideoDecoder

Comment 12

[Ashley Hale [:ahale]]

I like that logging in your patch - could that be changed to use AUTO_PROFILER_MARKER_UNTYPED or similar like I do in https://phabricator.services.mozilla.com/D240288 for the WindowsVsyncThread?

It is so much nicer to be able to navigate log messages on the marker chart in the Firefox profiler rather than looking at stderr and not being entirely sure when events occurred, often this lets me debug things more easily.

Comment 13

[Jen1]

I would like to follow up regarding the closure of my bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1962210. My findings were based on a comparison between Firefox and Edge, specifically concerning memory management and rendering performance.

In my report, I noted that there appears to be no memory leak in Edge, as memory is consistently evicted. Both browsers utilize ANGLE with Direct3D 11 rendering; however, I observed a significant difference in their OpenGL versions. In Edge, the GPU information shows "GL_VERSION: OpenGL ES 2.0.0" (accessible via edge://gpu/), while Firefox displays "OpenGL ES 3.0.0" in the about:support section.

This discrepancy seems to be impacting VRAM usage significantly, leading me to believe that the issue may be related to the driver rather than user settings. Additionally, I suspect that the older ANGLE library used by Firefox may be contributing to this problem, especially since Edge receives regular updates to its ANGLE library every week.

I would like to note that the memory leak is even worse in FF version 139.

Comment 14

[Jen1]

I reopened BUG 1962210

Comment 15

[Jen1]

I have been testing the changes mentioned in this comment, and they have resolved the memory leak issue on my setups. I would greatly appreciate it if someone could test the new ANGLE library to see if it also fixes the memory leak issue reported here.

Comment 16

[Alastor Wu [:alwu]]

Per comment15, move this to Graphic component because this issue seems caused by ANGLE.

Comment 17

[Alastor Wu [:alwu]]

Reset the priority and severity in order to let gfx team to triage this.

Comment 18

[Jen1]

As i stated in this comment:

I suspect that the missing extension, EGL_ANGLE_memory_usage_report, may be the cause of the memory leak According to the documentation here. Although the documentation pertains to Vulkan, the extension shares the same name and plays a crucial role in managing GPU memory, particularly in freeing up GPU resources.

Comment 19

[Jen1]

Bug 1971159

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bhood, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 21

[Alastor Wu [:alwu]]

Hi Ashley,
Would you be able to confirm whether Comment 18 is accurate? I also believe we should consider raising the priority of this bug, as the GPU memory leak could potentially impact many users. Thanks!

Comment 22

[KRM]

I can confirm that changing dom.ipc.processCount and dom.ipc.processCount.webIsolated to match the exact cores my laptop has, decreased RAM usage. But GPU process, specially linked to videos on Instagram/YouTube is a literal RAM hog, especially if more tabs are opened. Edge uses far less memory linked to GPU process on this same laptop. You should consider this critical, as Firefox becomes very slow if more GPU/Video tabs are opened.

Comment 24

[Ashley Hale [:ahale]]

(In reply to Jen1 from comment #18)

As i stated in this comment:

I suspect that the missing extension, EGL_ANGLE_memory_usage_report, may be the cause of the memory leak According to the documentation here. Although the documentation pertains to Vulkan, the extension shares the same name and plays a crucial role in managing GPU memory, particularly in freeing up GPU resources.

From my reading that extension is for analyzing memory usage as a debugging aid, its presence or absence is extremely unlikely to be related to the cause of memory leaks.

It is possible that extension could be used to debug memory leaks of ANGLE resources, but there are other ways to approach debugging that.

Comment 25

[E0]

I wanted to provide an update on this issue. The GPU dedicated memory leak in Firefox Nightly appears to be resolved in the latest build I tested. Unlike before, the VRAM usage now decreases appropriately when I close YouTube tabs, and I no longer observe the VRAM climbing to ~12 GB or causing a freeze

Firefox Nightly Ver: 143.0a1 (2025-07-22) (64-bit)

Comment 26

[Alastor Wu [:alwu]]

(In reply to E0 from comment #25)

I wanted to provide an update on this issue. The GPU dedicated memory leak in Firefox Nightly appears to be resolved in the latest build I tested. Unlike before, the VRAM usage now decreases appropriately when I close YouTube tabs, and I no longer observe the VRAM climbing to ~12 GB or causing a freeze

Firefox Nightly Ver: 143.0a1 (2025-07-22) (64-bit)

Yes, that is bug 1958438, but this bug is used to discuss the situation of using WMF decoder.

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.