Closed Bug 1696827 Opened 3 years ago Closed 4 months ago

Video memory leak on any long(ish)-running <video>

Categories

(Core :: Graphics: WebRender, defect, P2)

Firefox 88
x86_64
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox88 --- affected

People

(Reporter: 1justinpeter, Unassigned, NeedInfo)

References

Details

Attachments

(3 files)

Over time I have noticed a slow leak of video memory on Youtube. I see it reproducibly when watching a playlist of videos at 3-4x speed (via extension). After 1-2 hours, Firefox will freeze for 1-2 minutes at ~7.5GB (shared) video memory, before finally releasing the memory and unfreezing. Opening about:memory appears to set off this process (freezing the browser) early. As a result, I do not (yet) have a good memory capture/dump. I'm not sure if opening about:memory before the leak occurs will allow me to take a capture; otherwise, I assume I should be able to do so using task manager. In either of these situations, I'm not sure whether there will be any sensitive information involved and (if so) what the best way to get that to whoever the relevant person is would be.

About:support while watching Youtube and after a freeze is attached. (Interestingly, it appears to say that webrender failed to initialize. I'll have to look more to see if that's a persistent issue/what it may be caused by.) About:support from a new session will be attached below.

Due to the amount of time required to reproduce this issue, I have not yet verified the issue in any of the following circumstances:

  • Disabling fission
  • Updating to the latest graphics driver (my version is only ~2 months old, and the stable version installed by Windows)

Webrender appears to be starting normally, so it may be the case the the leak causes it to crash and fall back to another compositor.

Component: Audio/Video → Graphics: WebRender
Summary: Video memory leak on Youtube → Video memory leak on any long(ish)-running <video>

This occurs when playing any video, not just videos on youtube.

Watching one long video straight through, this led to full video memory and a freeze after 35 minutes of playback. (In other circumstances, it has taken longer.) It now appears to fall back to software webrender (it was falling back to a different compositor previously), which does not exhibit the issue.

(In reply to Justin Peter from comment #4)

Watching one long video straight through, this led to full video memory and a freeze after 35 minutes of playback. (In other circumstances, it has taken longer.) It now appears to fall back to software webrender (it was falling back to a different compositor previously), which does not exhibit the issue.

Sorry for the late reply. Does this mean you are no longer experiencing this issue?

Flags: needinfo?(1justinpeter)
Severity: -- → S3

Sorry, that wasn't quite clear. The issue still exists, but after webrender crashes and falls back to software webrender (previously it fell back to the basic compositor), I'm fairly certain that the issue will not pop up again in the same session.

If I get a process dump while it's in a leaky state, would that be of help?

Flags: needinfo?(1justinpeter) → needinfo?(mikokm)

I did manage to get two dumps: one from Firefox (attached), which seems to have no information other than that there is a lot of VRAM being used. I also captured a process dump (via task manager) of the process using lots of memory. Thankfully, it compressed very well (to 2% of the original size), but that report is presumably not anonymized, so if you have a good slightly-more-private way to send that to you, hopefully it could be more informative.

If there's anything else I could do to help, please feel free to ask.

Attached file memory-report.json.gz
Blocks: gfx-triage
See Also: → 1704774
Flags: needinfo?(mikokm)

gpu-committed is 3,336.96 MB and gpu-shared is 3,385.79 MB, that seems to be the biggest chunk, and it doesn't seem to be captured in our other reporting in the GPU process such as the texture host. This suggests either the reporting is missing stuff, or something inside Windows is holding onto that memory.

Would a Windows process dump help?

The see also post is on MacOS so that may indicate that it's not a Windows-specific bug.

Flags: needinfo?(aosmond)

Yes, I will contact you with a link where you can share the process dump, thanks.

Flags: needinfo?(aosmond)
No longer blocks: gfx-triage
Flags: needinfo?(aosmond)
Priority: -- → P2

I have not experienced this for several months.

I don't know if this was due to an update in Windows, Firefox, or my graphics driver. (The process dump may point to the root cause; I have no idea.)

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Do you still experience this issue?

Flags: needinfo?(1justinpeter)

No, I haven't experienced this for at least a year and a half.

Flags: needinfo?(1justinpeter)
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: