1200537 - Memory leak since Firefox 40 in conjunction with D3D11 WARP (Microsoft Basic Display Adapter)

Status: RESOLVED DUPLICATE of bug 1179504

(Core :: Graphics, defect)

Description

[Andre Schmidt]

Attachment: memory-reports.zip

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.

Comment 1

[Loic]

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".

Comment 2

[Timothy Nikkel (:tnikkel)]

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?

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 5

[Nicholas Nethercote [inactive]]

> 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.

Comment 6

[Andre Schmidt]

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

Comment 7

[Loic]

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.

Comment 8

[Andre Schmidt]

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

Comment 9

[Andre Schmidt]

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.

Comment 10

[Benoit Girard (:BenWa)]

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!