Closed Bug 1211204 Opened 4 years ago Closed 4 years ago
Possible d3d9-shared-texture leak
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 22.214.171.12429 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?
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?
(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
Sounds like there might be a leak in media textures then? Not sure who would know something about this.
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?
(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.
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).
I'd say bug 1072313...
[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.
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.
Attachment #8679355 - Flags: review?(matt.woodrow)
Attachment #8679355 - Flags: review?(matt.woodrow) → review+
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.