Build Identifier: https://hg.mozilla.org/mozilla-central/rev/6446c26b45f9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150119030222 Reproduced: always Steps To Reproduce: 1. Disable ANGLE and restart user_pref("webgl.disable-angle", true); user_pref("webgl.force-enabled", true); 2. Open http://webglsamples.org/aquarium/aquarium.html 3. Wait for a while (10-30sec) Actual Results: Huge GPU memory usage. Finally browser/OS hangs up. 0.00 MB ── gfx-d2d-surface-cache 4.00 MB ── gfx-d2d-surface-vram 0.00 MB ── gfx-d2d-vram-draw-target 0.00 MB ── gfx-d2d-vram-source-surface 0.00 MB ── gfx-textures 0.00 MB ── gfx-tiles-waste 0 ── ghost-windows 2,787.39 MB ── gpu-committed 874.16 MB ── gpu-dedicated 51.09 MB ── gpu-shared 2,374.41 MB ── heap-allocated 2,959 ── heap-chunks 1.00 MB ── heap-chunksize 2,378.77 MB ── heap-committed 2,959.00 MB ── heap-mapped 0.18% ── heap-overhead-ratio 0.26 MB ── imagelib-surface-cache-estimated-locked 42.65 MB ── imagelib-surface-cache-estimated-total 0.30 MB ── js-main-runtime-temporary-peak 0 ── low-commit-space-events 2,622.67 MB ── private 2,605.92 MB ── resident 3,626.88 MB ── vsize 240.59 MB ── vsize-max-contiguous 448 ── webgl-buffer-count 2.58 MB ── webgl-buffer-memory 2 ── webgl-context-count 0 ── webgl-renderbuffer-count 0.00 MB ── webgl-renderbuffer-memory 74 ── webgl-shader-count 182 ── webgl-texture-count 151.67 MB ── webgl-texture-memory Regression window(m-i) Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/81b10ae50d1e Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20141010125902 Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/216915390f9b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20141010130606 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=81b10ae50d1e&tochange=216915390f9b Regressed by: Bug 1066280 Graphics -------- Adapter Description: AMD Radeon HD 6450 Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM: 1024 ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200 Device ID: 0x6779 Direct2D Enabled: true DirectWrite Enabled: true (6.2.9200.16571) Driver Date: 11-20-2014 Driver Version: 14.501.1003.0 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Subsys ID: 23111787 Vendor ID: 0x1002 WebGL Renderer: ATI Technologies Inc. -- AMD Radeon HD 6450 windowLayerManagerRemote: true AzureCanvasBackend: direct2d 1.1 AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0

I don't know what it means for WebGL to be enabled and for ANGLE to be disabled? Does that disable interop with the compositor and cause readback or something?

(In reply to Bas Schouten (:bas.schouten) from comment #1) > I don't know what it means for WebGL to be enabled and for ANGLE to be > disabled? Sorry, it is for just test Bug 1123297 . So, this is not a big problem. maybe WONTFIX ?

(In reply to Bas Schouten (:bas.schouten) from comment #1) > I don't know what it means for WebGL to be enabled and for ANGLE to be > disabled? Does that disable interop with the compositor and cause readback > or something? Yes. We would then use the system GL libs and do readback. Looks like we might be leaking something, or at least holding onto it too long.

These allocations are reclaimed when switching to another tab in the same window, so I had to run about:memory in a separate window to capture these. Here is the diff between two reports about 20 seconds apart. 1,195.64 MB (100.0%) -- explicit ├──1,193.16 MB (99.79%) -- gfx │ ├──1,193.16 MB (99.79%) ── heap-textures These are ImageDataSerializer buffers coming from: mozglue!je_malloc xul!mozilla::layers::MemoryTextureClient::Allocate xul!mozilla::layers::BufferTextureClient::AllocateForSurface xul!mozilla::layers::TextureClient::CreateForRawBufferAccess xul!mozilla::layers::TexClientFactory::Create xul!mozilla::layers::TexClientFromReadback xul!mozilla::layers::CanvasClientSharedSurface::Update xul!mozilla::layers::ClientCanvasLayer::RenderLayer xul!mozilla::layers::ClientLayer::RenderLayerWithReadback xul!mozilla::layers::ClientContainerLayer::RenderLayer xul!mozilla::layers::ClientLayer::RenderLayerWithReadback xul!mozilla::layers::ClientContainerLayer::RenderLayer xul!mozilla::layers::ClientLayerManager::EndTransactionInternal xul!mozilla::layers::ClientLayerManager::EndTransaction xul!nsDisplayList::PaintRoot (I filed bug 1127159 for some overallocation I noticed, but that is unrelated to this "leak")

Can the allocations in comment 4 happen outside of this pref configuration? If disabling ANGLE is truly the only way to hit this, then I agree with the low priority. But maybe it could point us to more general wins?