This bug was filed from the Socorro interface and is report bp-d7d008ec-af8e-4405-8086-924372160131. ============================================================= Here is a OOM when we're trying to upload a giant (24MB in this case) texture. Probably a good place to look at for gfx OOM in general.

The allocation that seems to be OOMing is in TexSubImage2DWithoutUnpackSubimage, where we allocate and copy the entire texture. I guess the main question here is why do we have a 24MB texture in the first place? At upload time in this scenario we will require 3x that amount: once for original data, once for the copy here in TexSubImage2DWithoutUnpackSubimage, and presumably one more for the texture itself. That's a lot, though we will throw at least one of those copies away immediately.

Sotaro, can you see if there is a better way to deal with such large requests?

a testcase is created by modifying attachment 8584779 [details] of Bug 1148582. It created a very large mask layer.

MaskLayer is created by ContainerState::CreateMaskLayer(). https://dxr.mozilla.org/mozilla-central/source/layout/base/FrameLayerBuilder.cpp#5975 MaskLayer data is stored as SourceSurfaceImage. SourceSurfaceImage::GetTextureClient() allocates duplicated memory as TextureClient. It seems better to avoid to allocate duplicated memory if possible. https://dxr.mozilla.org/mozilla-central/source/gfx/layers/ImageContainer.cpp#563

Bug 1252405 is created for Comment 4.

(In reply to Sotaro Ikeda [:sotaro] from comment #7) > https://treeherder.mozilla.org/#/jobs?repo=try&revision=c3aa0d6e13d3 The patch seemed to cause some test failures.

Jeff recommended to allocate a mask as to aligned to 4 byte as a short term solution.

Add fuzz to tests.