Closed Bug 1211204 Opened 4 years ago Closed 4 years ago

Possible d3d9-shared-texture leak

Categories

(Core :: Graphics: Layers, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla44
Tracking Status
firefox44 + fixed

People

(Reporter: guijoselito, Assigned: nical)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 file)

After browsing after a few hours without closing Nightly, I checked the Windows Task Manager and Nightly was consuming 970 MB of memory.
Checking about:memory there was 600 MB under explicit. I closed all the tabs, leaving only about:memory open.
Explicit dropped to 340 MB (119 MB of heap-overhead and 66 MB of heap-unclassified), but Windows Task Manager still was showing 650 MB for Nightly.
I scrolled down about:memory and saw "594.62 MB ── d3d9-shared-texture".
Nightly has been consuming more memory than the usual in the last few days or even weeks but I can't confirm that this (high d3d9) was happening before as well.

The pages I browsed around in this session were Gmail, Facebook and https://www.flickr.com/photos/nissan-racing/ (I browsed until page 13 and downloaded a few photos).
From about:support

Graphics
Adapter Description	Intel(R) HD Graphics 3000
Adapter Drivers	igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
Adapter RAM	Unknown
Asynchronous Pan/Zoom	none
Device ID	0x0116
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.17461)
Driver Date	5-26-2015
Driver Version	9.17.10.4229
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	00000000
Supports Hardware H264 Decoding	Yes
Vendor ID	0x8086
WebGL Renderer	Google Inc. -- ANGLE (Intel(R) HD Graphics 3000 Direct3D11 vs_4_1 ps_4_1)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

I'm having this problem almost every session... I guess only browsing on Facebook for a long time is enough.
I don't want to annoying, but this problem seems very important, if it happens to a lot more people than just me. It's been 10 days without this getting noticed.

I have a d3d11 capable machine, and this memory that doesn't go away is on d3d9. I'm with e10s off.
Guilherme could you try (temporarily) setting "media.hardware-video-decoding.enabled" to false in about:config, restarting Firefox, and seeing if the problem still occurs?
Flags: needinfo?(guijoselito)
Whiteboard: [gfx-noted]
The D3D9 vs. D3D11 is a confusing item, I admit, but it's a red herring.  The memory tagged as "d3d9-shared-texture" is only used by D3D11 compositor, so you should be fine on that front.  :nical, are there any logging (e.g., MOZ_COUNT_CTOR/DTOR etc.) things that we can use to double check if there is a leak?
Flags: needinfo?(nical.bugzilla)
(In reply to David Anderson [:dvander] from comment #3)
> Guilherme could you try (temporarily) setting
> "media.hardware-video-decoding.enabled" to false in about:config, restarting
> Firefox, and seeing if the problem still occurs?

This indeed makes 'd3d9-shared-texture' be equal to 0 all the time, but memory still is going somewhere. I have only about:memory open and Windows Task Manager shows Nightly consuming 540 MB (but maybe that's another problem, like fragmentation)

With media.hardware-video-decoding disabled I get:
14.43 MB ── canvas-2d-pixels
18.44 MB ── d3d11-shared-textures
0.00 MB ── d3d9-shared-texture
175.59 MB ── heap-committed
306.34 MB ── heap-mapped
644.93 MB ── resident
Flags: needinfo?(guijoselito)
Sounds like there might be a leak in media textures then? Not sure who would know something about this.
Flags: needinfo?(matt.woodrow)
My guess is that this is related to bug 1205559.

Nical, should we wait for your rewrite of this stuff, or try to fix that now?
Flags: needinfo?(matt.woodrow)
(In reply to Matt Woodrow (:mattwoodrow) from comment #7)
> My guess is that this is related to bug 1205559.
> 
> Nical, should we wait for your rewrite of this stuff, or try to fix that now?

I'll extract the relevant parts from Jean-Yves's patch in bug 1205559 as a short-term fix. I am hoping that the rewrite won't take long but the deeper I delve into it the scarier and more entangled things appear to be.
Flags: needinfo?(nical.bugzilla)
On today's Nightly I'm still seeing this. After a few hours browsing, then closing everything and just opening this page:

Windows Task Manager says 690 MB

about:memory

   40.35 MB ── canvas-2d-pixels
   21.20 MB ── d3d11-shared-textures
  275.87 MB ── d3d9-shared-texture
    0.00 MB ── d3d9-shared-textures
    0.00 MB ── gfx-d2d-vram-draw-target
    0.00 MB ── gfx-d2d-vram-source-surface
    0.10 MB ── gfx-surface-win32
    0.00 MB ── gfx-textures
    0.00 MB ── gfx-tiles-waste
          0 ── ghost-windows
  198.40 MB ── gpu-committed
    2.58 MB ── gpu-dedicated
  222.34 MB ── gpu-shared
  155.09 MB ── heap-allocated
      4,711 ── heap-chunks
    0.06 MB ── heap-chunksize
  194.67 MB ── heap-committed
  294.45 MB ── heap-mapped
     25.52% ── heap-overhead-ratio
          1 ── host-object-urls
    0.65 MB ── imagelib-surface-cache-estimated-locked
    0.81 MB ── imagelib-surface-cache-estimated-total
          0 ── imagelib-surface-cache-overflow-count
    1.86 MB ── js-main-runtime-temporary-peak
          0 ── low-commit-space-events
  779.52 MB ── private
  793.93 MB ── resident
   11.17 MB ── system-heap-allocated
1,392.00 MB ── vsize
1,805.94 MB ── vsize-max-contiguous

If/when I have free time, I'll try to find the first build this started to happen.
After using the builds from https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-win32-pgo/ I've found a regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=abe43c30d78d7546ed7c622c5cf62d265709cdfd&tochange=4a46de29431baa621d98d8f1168e43297ce1a916

My STR:
1 - start Nightly
2 - open about:memory and measure - see 0 or close to that on d3d9-shared-texture
3 - load https://pt-br.facebook.com/nissanbrasil - on Windows Task Manager Nightly memory goes to 700MB
4 - measure again on about:memory - ~160MB of d3d9-shared-texture
5 - close the facebook page, wait 20secs (or just look on WTM when Nightly reduces its memory) and measure again

On the good builds, d3d9-shared-texture is 0 after these steps. On the first bad build, that number doesn't go below 120MB.

Just a curiosity: AWSY has a regression for the same day, but different regression range (I know that it's Linux there, but the problem is the same - memory not being released).
Flags: needinfo?(nical.bugzilla)
I'd say bug 1072313...
Flags: needinfo?(matt.woodrow)
[Tracking Requested - why for this release]: We don't want a memory leak regression in 44.
Bug 1072313 seems like the most likely option, in particular nical's patch from it.

My guess is that FinalizeOnIPDLThread isn't being called for some SharedTextureClientD3D9 instances.

Looking back at the original bug, nical said this can happen if we never allocated the actor for the TextureClient.

In this case mTexture would still be released (since it's refcounted, and the dtor would drop the ref), but our manual management of sD3D9SharedTextureUsed wouldn't be updated and we'd report a (fake) leak.
Flags: needinfo?(matt.woodrow)
And even fake leaks are bad because they may hide real leaks...  nical, I'm assigning to you, but if you can't get to it this week (we're going to Aurora with 44 in a week), let me know and we'll find help.
Assignee: nobody → nical.bugzilla
Matt's explanation makes sense. Let's try this.
Flags: needinfo?(nical.bugzilla)
Attachment #8679355 - Flags: review?(matt.woodrow)
Attachment #8679355 - Flags: review?(matt.woodrow) → review+
https://hg.mozilla.org/mozilla-central/rev/98c007c60415
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
With today's Nightly, after the STRs, the result is 0 again!
Status: RESOLVED → VERIFIED
Tracking for FF44 (even though it's already fixed) because memory leaks are bad.
You need to log in before you can comment on or make changes to this bug.