+++ This bug was initially created as a clone of Bug #1087043 +++ Bug 1127925 fixed some of these problems in 38, uplifted to all the way, but we have reports of the same problem, or something similar still being there in 38 and now 39. See https://bugzilla.mozilla.org/show_bug.cgi?id=1087043#c30, https://bugzilla.mozilla.org/show_bug.cgi?id=1087043#c31, https://bugzilla.mozilla.org/show_bug.cgi?id=1087043#c33. For example: "After watching HTML5 videos (mainly on Youtube) for some time, memory consumption of firefox.exe goes through the roof. Before GUI elements start to vanish and stop responding and eventually the program crashes, memory usage grows to about 1GiB of private bytes and 1.5GiB of virtual set." "Same thing for me. The only way I've found to watch videos without this problem is to use FF in safe mode."

Can we have about:support graphics section of the machines that exhibit this problem?

Bug 1183920 may have helped here; it landed on beta 40 only a few days ago, and after the last 40 beta 6 build I think.

Yes, sure: Grafica Data aggiornamento driver 10-9-2006 Descrizione scheda grafica NVIDIA GeForce FX 5700LE DirectWrite attivo false (6.1.7600.16385) Driver scheda grafica nvd3dum Finestre con accelerazione GPU 1/1 Direct3D 11 WARP (OMTC) GPU #2 attiva false ID dispositivo 0x0343 ID produttore 0x10de ID sottosistema 00000000 Panoramica/zoom asincroni (APZ) none RAM scheda grafica 256 Rendering WebGL Google Inc. -- ANGLE (NVIDIA GeForce FX 5700LE Direct3D9Ex vs_2_0 ps_2_0) Versione driver 9.6.8.5 windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend cairo AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0

Can somewhat confirm this or a similar bug on 40b8. I'll see a loss of responsiveness after watching videos over a day and notice that Firefox.exe is eating 1.5GB with only a couple tabs open. I'll use SysInternals ProcExp to report memory use. Baseline memory, with only this tab open after a fresh process reset: Private Bytes: ~300K, Working Set: ~311K, After watching 47 minutes of YouTube video at 720p60; Video tab still open: Private bytes: ~560K, Working set: ~530K Tab closed: PB ~520K, WS ~490K I reset the process and watched 20 min of 1080p60 video; Tab still open: PB ~630K, WS ~560K Tab closed: PB ~574K, WS ~500K In the Windows task manager the reported memory use doubles, too. Anyway, hope this helps. Graphics Adapter Description AMD Radeon (TM) R9 200 Series Adapter Drivers aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM 2048 Asynchronous Pan/Zoom none ClearType Parameters Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100 Device ID 0x6811 Direct2D Enabled true DirectWrite Enabled true (6.2.9200.17292) Driver Date 6-22-2015 Driver Version 15.200.1046.0 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 11 (OMTC) Subsys ID 00000000 Supports Hardware H264 Decoding true Vendor ID 0x1002 WebGL Renderer Google Inc. -- ANGLE (AMD Radeon (TM) R9 200 Series Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote true AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0

(In reply to Alexander B. from comment #4) > I'll use SysInternals ProcExp to report memory use. Please go to about:memory in such a situation, save a memory report from there and attach it here if possible.

We think there are memory leaks associated with WARP and Windows 7, but comment 4 seems to be Windows 8 and no WARP, so this would be something else.

(In reply to Milan Sreckovic [:milan] from comment #6) > We think there are memory leaks associated with WARP and Windows 7, but > comment 4 seems to be Windows 8 and no WARP, so this would be something else. Sorry for the lack of information. I'm in Win7 but am using hardware acceleration both on videos and in the advanced options. I was able to replicate memory usage hovering at 1+GB by opening about 8 youtube videos side-by-side in separate tabs then closing them all. I reported the results of that test in the attachments above. I was not able to replicate the elevated memory use when opening 8 videos sequentially in the same tab -- in that case, the memory was successfully freed and usage stayed below 600 MB.

8 tabs of YouTube video will use about 1GB of RAM as one mediasource object (there's one per video) will use 100MB for video (75MB in 39/40) and about 20MB for audio. So nothing alarming there. Closing the tabs should release memory associated with those buffers.

(In reply to Jean-Yves Avenard [:jya] from comment #10) > 8 tabs of YouTube video will use about 1GB of RAM as one mediasource object > (there's one per video) will use 100MB for video (75MB in 39/40) and about > 20MB for audio. > > So nothing alarming there. > > Closing the tabs should release memory associated with those buffers. That report was taken 10 minutes after closing all the youtube tabs. That's the bug I'm experiencing.

Bas, here's another "leaking memory during video, and not just with WARP".

I can happily report that I cannot reproduce my specific problem on 40b9.

(In reply to Alexander B. from comment #4) > Can somewhat confirm this or a similar bug on 40b8. I'll see a loss of > responsiveness after watching videos over a day and notice that Firefox.exe > is eating 1.5GB with only a couple tabs open. I experience this with 42.0a1 (2015-08-01). Have been experiencing this for weeks.

Closing tabs with videos doesn't help.

Roman R., can you please file a separate bug? Symptoms like these may well have different causes for different people, and it can be confusing if multiple people report symptoms in a single bug. If your problem does end up having the same cause, we can mark one of the bugs as a duplicate of the other. Thank you.

I have the same issue with FF 40.0.2, on Intel i5 @3.2Ghz, 4Gb of RAM and Windows 7 Professional SP1 (32bit)

This is interesting. But I don't see anything directly actionable here, do you, Matt?

Roman, can you please attach the contents of your graphics sections of about:support.

With version 40.0.2 it seems to be ok, to me.

Nobody responding to this bug.