Allocating big buffers with the infallible allocator is not safe, especially with the memory constraints we have on some of the B2G devices.

Why is it not safe? infallible means we should crash which wont be exploitable. If we switch to fallible allocations we need a way to fallback gracefully. Do you have a suggestion how to fallback gracefully?

I think that an incorrectly rendered layer (I mean aborting the update of the layer if we could not allocate it, miss a few frames, whatever) with warnings in the logs is better than a crash. It's certainly a debatable question. Crashes are good to raise awarness of issues and for debuggability (and I'd gladly crash debug builds in this case) but there is nothing worse for users (with the exception of security vulnerabilities).

Comment on attachment 8341746 [details] [diff] [review] Let MemoryTextureClient use fallible allocation. Review of attachment 8341746 [details] [diff] [review]: ----------------------------------------------------------------- The (indirect) result of Allocate isn't checked properly: http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/SharedRGBImage.cpp#87

Oops, you are right!

We keep having this discussion about what to do with layers when we can't allocate. I think we should take an official stance on this rather then be inconsistent. We could also use a checkerboard like texture to indicate a layer couldn't be allocated.

That seems fine to me. I don't think we need to both with checkerboarding though. Once we run so low on memory that we can't allocate screen sized surfaces the whole browser is about to fall apart anyway. In the case where the texture client is considerably bigger than the screen, then we should look at not doing that.

Comment on attachment 8342324 [details] [diff] [review] Let MemoryTextureClient use fallible allocation Alright lets land it

Comment on attachment 8342324 [details] [diff] [review] Let MemoryTextureClient use fallible allocation [Approval Request Comment] Bug caused by (feature/regressing bug #): - User impact if declined: Crashes on OOM on some Android devices. See bug 945821. Testing completed (on m-c, etc.): Haven't seen the same crash in Aurora+ Risk to taking this patch (and alternatives if risky): None String or IDL/UUID changes made by this patch: None