User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171211105838 Steps to reproduce: 1. Go to youtube.com 2. Play a video with quality set to 1080p60 Actual results: 1. Modified memory will slowly increase, up to your total amount of system memory 2. CPU will be maxed out at 100% usage on all cores 3. Closing Firefox causes the memory to slowly drop back down to normal as modified memory is written to the disk Expected results: 1. All system memory should not be used 2. CPU usage should not be maxed out on all cores

Memory report

I wasn't able to reproduce this with a 10-minute video on youtube. Do you have a specific youtube video you were watching when this happened? How long did it take to increase to your total memory? Also, can you attach a copy of your about:support contents? Thanks!

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #2) > I wasn't able to reproduce this with a 10-minute video on youtube. Do you > have a specific youtube video you were watching when this happened? How long > did it take to increase to your total memory? Also, can you attach a copy of > your about:support contents? Thanks! I have attached my about:support contents. Looking into it more, the memory leak does not seem to be exclusive to the 1080p60 video quality. This video at 1080p uses up 16GB of memory after 4 minutes, when Firefox then stops responding: https://www.youtube.com/watch?v=C666j39s3wc This video at 1080p60 uses up 12GB of memory by the time the video ends: https://www.youtube.com/watch?v=gu6JunBsyUQ The videos are using these codecs: avc1.640028 (137) / mp4a.40.2 (140) avc1.64002a (299) / mp4a.40.2 (140)

Thanks! With this video I can reproduce the issue you're seeing, where memory use keeps climbing. However in my case the modified memory amount remained relatively constant, it didn't grow as much as indicated in your screenshot. The behaviour pattern I'm seeing corresponds with a slow memory leak, which I guess is not too surprising, we probably have a bunch of those. In your case there's a few things that jump out - for one thing the amount of compressed memory on your system is quite low. When the modified memory grows the memory compression should kick in and write that modified memory into compressed memory, which should bring down the modified memory numbers and increase the compressed memory numbers. It might be that because your CPU utilization is at 100% the memory compressor never gets to run the low-priority background compression tasks, and so this doesn't happen until you have no more physical memory. In my case the CPU utilization is around 35-40% while the video is playing and so the compression happens fairly continuously, which is why my modified memory numbers remain relatively constant. The other thing to note is that the task manager displays physical memory as opposed to virtual memory, so even if the memory utilization goes to 100% it should just page to disk and shouldn't actually cause Firefox to stop responding (although it may respond slower because the system is doing disk I/O). So that's puzzling as well. Again it might just be too much load on the CPU and the system is trying to do too much to be responsive - that's my current best guess.

Also a note: in my case the memory usage dropped significantly if I switched tabs away from the video, so it's likely that the memory we're leaking is not really fully leaked, it's just not freed as soon as it could be. In order to use about:memory and about:support without interfering with the video tab I had to open those into new windows.

Here's the top of the DMD report from the GPU process, in case it's useful later.

I could reproduce the problem. The problem seems to related to codec type. I did not see the problem with VP9 with https://www.youtube.com/watch?v=1La4QzGeaaQ

Memory seems to be leaked within ANGLE related to RenderDXGITextureHostOGL and RenderDXGIYCbCrTextureHostOGL for video case. For video, the followings are used, they might be related to the leak. egl->fStreamConsumerGLTextureExternalAttribsNV() egl->fCreateStreamProducerD3DTextureNV12ANGLE() egl->fStreamPostD3DTextureNV12ANGLE()

(In reply to Sotaro Ikeda [:sotaro] from comment #9) > > For video, the followings are used, they might be related to the leak. > egl->fStreamConsumerGLTextureExternalAttribsNV() > egl->fCreateStreamProducerD3DTextureNV12ANGLE() > egl->fStreamPostD3DTextureNV12ANGLE() When they are commented out, I did not saw the memory leak.

I found the problem that EGLStreamKHR was leaked in RenderDXGITextureHostOGL and RenderDXGIYCbCrTextureHostOGL. They tries to destroy EGLStreamKHR by eglStreamConsumerReleaseKHR, but it does not destroy StreamConsumerReleaseKHR. To destroy EGLStreamKHR, we need to call eglDestroyStreamKHR. Further eglStreamConsumerReleaseKHR was failed because, it was called after deleting attached GL texture. Deleting the attached GL texture triggers Stream::releaseTextures() calling and it invalidated the stream.

Confirmed that attachment 8941285 [details] [diff] [review] addressed the memory leak for me.

Pushed by sikeda@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f46dc31cb321 Call eglDestroyStreamKHR during deleting EGLStreamKHR r=jgilbert

I've tested this issue on 59.0a1 (2017-12-11) under Windows 10 x64 by: - changing the Graphic compositing to WebRender (by setting the gfx.webrender.enabled on true) - installing all the Add-ons mentioned in about_support.txt from comment 3 - playing the videos mentioned in comment 4 (with the video quality set on 1080p) I was able to reproduce the behavior mentioned in comment 4: the memory increased, but reaching no more that 65%, while the CPU was most of the time over 90% on all cores. After about 4 minutes the browser freezed and the tab bar turned completly white. All the other attempts concluded indeed in memory increase, but once reaching a certain percent (65%-66%), it remained relatively constant. I retested the issue on the latest Nightly 60.0a1 (2018-02-07) using the same steps above (except this time I used the gfx.webrender.all set on true) with the following results: - The memory remains generally constant at no more than 48%, while the CPU was most of the time under 25% for the first video - The memory remains generally constant at no more than 48%, while the CPU was most of the time between 30% and 40% for the second video - The memory remains generally constant at no more than 54%, while the CPU was most of the time between 40% and 60%, when playing both videos at once. I see that I can't set the Graphic compositing to WebRender on latest beta, 59.0b7. Moreover, the 59 build is flagged as disabled. Is this because WebRender can be enabled only in Firefox Nightly?

WebRender is only included/built in Nightly. There is bug 1432515, but just as a thought. https://groups.google.com/forum/#!topic/mozilla.dev.tech.gfx/916NeNdjg3U

Based on the testing conclusions mentioned in comment 17 and on the confirmation received in comment 18, about webrender being disabled on beta 59, I can marked this bug as verified fixed on Firefox 60.0a1.