User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150826023504 Steps to reproduce: After several diagnoses, we found the following facts: - about:memory indicates a very high vsize consumption. Our web application remains constant under 100MB. - The problem occurs only since Firefox 40. We could not reproduce it with previous versions. - If we disable hardware acceleration, the problem disappears. - We can only reproduce the problem on computers running the "Microsoft Basic Display Adapter" as graphics card. - The trigger in our web application is a timer that updated a label once per second. The Label is used to show the session timeout. Otherwise, the website is complex but static. - During measurements no interaction took place on our website. - Scaling up the Firefox window appears to correlate with the memory growth. Once the session label is no longer visible by scaling down the window, the memory usage does not increase further. - After changing to a different web page, the used memory seems not to be released. Unfortunately, we have not found any public website yet, with which we can reproduce the problem. Our web application is currently not open to the public, because it is used only as a front-end for managing our back-end software. If necessary, I could see if we can provide a version of our software. However, this version has to be installed by an installer. The appendix contains the following memory reports: - Before starting the web application: Memory-report (initial) - Shortly after the start of the web application: Memory-report (1) - About 8 minutes after the start of the web application: Memory-report (2) Actual results: Starting with Firefox 40 it seems there is a massive memory leak, when we are running our web application. The consumption increases per second partially to several megabytes until Firefox is barely operable. Expected results: The memory usage should be constant.

Could you type about:support in the location bar and copy the section "graphics", it would give useful details about your system. In addition, if it worked in the previous versions of Firefox, you can install the tool Mozregression to find a possible regression range. See http://mozilla.github.io/mozregression/install.html for details (install the command line version). Just rune the command "mozregression --good-release 39".

From memory-report (2).json in the attachment: 4,095.94 MB (100.0%) -- address-space ├──3,330.66 MB (81.32%) -- commit │ ├──3,113.11 MB (76.00%) -- private │ │ ├──3,107.12 MB (75.86%) ── readwrite [2626] When I see huge vsize but tiny explicit (160mb) I suspect graphics memory in some way. Does this suggest the graphics driver is using the memory?

From the description, it sounds like a surface is being created, likely window-sized, whenever the label is updated. This surface is then either leaked or just not being freed, either by us or by the underlying driver.

(In reply to Timothy Nikkel (:tn) from comment #2) > From memory-report (2).json in the attachment: > > 4,095.94 MB (100.0%) -- address-space > ├──3,330.66 MB (81.32%) -- commit > │ ├──3,113.11 MB (76.00%) -- private > │ │ ├──3,107.12 MB (75.86%) ── readwrite [2626] > > When I see huge vsize but tiny explicit (160mb) I suspect graphics memory in > some way. Does this suggest the graphics driver is using the memory? That's very possible. Tracking these things down is not always very easy, especially without being able to reproduce.

> When I see huge vsize but tiny explicit (160mb) I suspect graphics memory in > some way. Does this suggest the graphics driver is using the memory? Yes, especially because of this: > - If we disable hardware acceleration, the problem disappears. The "Microsoft Basic Display Adapter" seems to be a safe fallback gfx driver that is used in some cases -- see https://msdn.microsoft.com/en-us/library/windows/hardware/Dn653353%28v=VS.85%29.aspx. I don't have a good sense of how commonly it is used. If it's common then that makes this bug a higher priority.

We have currently three systems on which we can reproduce the problem (see System1 to System3 below). The evaluation of the about: support data has brought us new insights: The problem occurs when you are using Remote Desktop Connection on a system and when the physical video card drivers (for example, the "Microsoft Basic Display Adapter") has apparently special properties. It seems that the Remote Desktop Connection triggers the problem and the "Microsoft Basic Display Adapter" only creates the corresponding error-prone environment and does not have to be installed necessarily. Here is the requested information: System 1 (memory leak occurred): ============================= - Graphics card: Microsoft Basic Display Adapter - Remote Desktop Connection used. Grafik Asynchrones Wischen und Zoomen: nichts Direct2D aktiviert: Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen. DirectWrite aktiviert: false (6.3.9600.16384) Geräte-ID: 0x0000 GPU #2 aktiv: false GPU-beschleunigte Fenster: 1/1 Direct3D 11 WARP (OMTC) H264-Hardware-Dekodierung unterstützt: false Karten-Beschreibung: RDPUDD Chained DD Karten-RAM: Unknown Karten-Treiber: RDPUDD Subsys-ID: 00000000 Vendor-ID: 0x0000 WebGL-Renderer: Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen. windowLayerManagerRemote: true AzureCanvasBackend: skia AzureContentBackend: cairo AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0 System 2 (memory leak occurred): ============================= - Graphics card: Microsoft Basic Display Adapter - Remote Desktop Connection used. Grafik Asynchrones Wischen und Zoomen nichts Direct2D aktiviert Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen. DirectWrite aktiviert false (6.3.9600.16384) Geräte-ID 0x0000 GPU #2 aktiv false GPU-beschleunigte Fenster 1/1 Direct3D 11 WARP (OMTC) H264-Hardware-Dekodierung unterstützt false Karten-Beschreibung RDPUDD Chained DD Karten-RAM Unknown Karten-Treiber RDPUDD Subsys-ID 00000000 Vendor-ID 0x0000 WebGL-Renderer Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen. windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend cairo AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0 System 2 (no memory leak): ============================= - Graphics card: Microsoft Basic Display Adapter - Direct access to the system. Remote Desktop Connection _not_ used. Grafik Asynchrones Wischen und Zoomen nichts Direct2D aktiviert true DirectWrite aktiviert true (6.3.9600.16384) Geräte-ID 0x0f00 GPU #2 aktiv false GPU-beschleunigte Fenster 1/1 Direct3D 11 (OMTC) H264-Hardware-Dekodierung unterstützt false Karten-Beschreibung Microsoft Basic Display Adapter Karten-RAM 0 Karten-Treiber Unknown Subsys-ID 00000000 Treiber-Datum 6-21-2006 Treiber-Version 6.3.9600.16384 Vendor-ID 0x10de WebGL-Renderer Google Inc. -- ANGLE (Microsoft Basic Render Driver Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote true AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0 System 3 (memory leak occurred): ============================= - Graphics card: Virtual Machine with _another graphics card_ (no Microsoft Basic Display Adapter) - Remote Desktop Connection used. Grafik Asynchrones Wischen und Zoomen nichts Direct2D aktiviert Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen. DirectWrite aktiviert false (6.3.9600.17795) Geräte-ID 0x0000 GPU #2 aktiv false GPU-beschleunigte Fenster 1/1 Direct3D 11 WARP (OMTC) H264-Hardware-Dekodierung unterstützt false Karten-Beschreibung RDPUDD Chained DD Karten-RAM Unknown Karten-Treiber RDPUDD Subsys-ID 00000000 Vendor-ID 0x0000 WebGL-Renderer Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen. windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend cairo AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0 System 4 (no memory leak): ============================= - Graphics card: ATI FirePro V3700 (no Microsoft Basic Display Adapter) - Remote Desktop Connection used. Grafik Asynchrones Wischen und Zoomen: nichts Direct2D aktiviert: Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen. DirectWrite aktiviert: false (6.2.9200.17461) Geräte-ID: 0x0000 Geräte-ID (GPU #2): 0x95cc GPU #2 aktiv: false GPU-beschleunigte Fenster: 0/13 Basic (OMTC) Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen. H264-Hardware-Dekodierung unterstützt: false Karten-Beschreibung: RDPDD Chained DD Karten-Beschreibung (GPU #2): ATI FirePro V3700 (FireGL) Karten-RAM: Unknown Karten-RAM (GPU #2): 256 Karten-Treiber: RDPDD Karten-Treiber (GPU #2): atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Subsys-ID: 00000000 Subsys-ID (GPU #2): 0000000c Treiber-Datum (GPU #2): 8-17-2009 Treiber-Version (GPU #2): 8.632.1.2000 Vendor-ID: 0x0000 Vendor-ID (GPU #2): 0x1002 WebGL-Renderer: Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen. windowLayerManagerRemote: true AzureCanvasBackend: skia AzureContentBackend: cairo AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0 Mozregression Results: ======================== 2:49.22 LOG: MainThread Bisector INFO Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4d6d69 f0f499dfc5c67df291858feda7bd2b9eac&tochange=d0fc7202b4cbe1ac8de823ed9e1e6dad706f c4d0

That sounds like a WARP issue on Win 7 (according to your user agent), and there is bug 1179504 about a similar issue. Maybe bug 1179504 could fix your issue.

In addition: On the problematic systems (1-3) is Windows Server 2012 R2 installed. The last-mentioned system (4) where Firefox's memory usage is constant in spite of the Remote Desktop Connection is a Windows 7. System 1: User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 System 2: User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 System 3: User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 System 4: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0

Bug 1179504 is marked as duplicate of bug 1188831. There I have found and tested the following configuration value. If I set layers.d3d11.disable-warp to true, the problem disappears.

Looks like you were testing with FF40. WARP will be disabled on win7 there so the leak should go away. We will still disable it in FF42+. I think this can be resolved as being a dupe of bug 1179504. Thanks for providing us with the necessary information to investigate this!