Our OOM testing machinery hits false positives in IonBuilder where it tries to allocate something from the TempAlloc, and we inject a failure there, and of course it crashes, because it's supposed to be impossible for an error to occur there, due to ballast. In debug builds, we should track how many bytes of ballast we have left, and assert it never reaches 0. If that assertion ever hits, it'll be easy to add another ensureBallast() call somewhere.

Most of this issue seems to be fixed by Bug 1155618. The code path of the allocator got moved into the allocImpl functions, which is no longer used by the allocInfallible which has the AutoEnterOOMUnsafeRegion section which reports an unhandlable OOM. I think we should not report them as unhandlable oom … I will work on that.

This patch prevent us from reporting unhandlable oom for the TempAlloc (only user of the Lifo allocInfallible function). The TempAllocator issues can be handled by allocating more ballast space in for-loops which are doing multiple allocations.

We should not land this bug before much more fuzzing is made on this patch, as this replace a failure by some code which is considered to be infallible. Maybe it would make sense to have a MOZ_RELEASE_ASSERT instead.

Comment on attachment 8670245 [details] [diff] [review] Ensure that we can check for OOMs when we run out of ballast space. Review of attachment 8670245 [details] [diff] [review]: ----------------------------------------------------------------- Yeah, I think the idea makes sense but this should be a MOZ_RELEASE_ASSERT.

This patch makes sure that the TempAllocator used by IonMonkey reports non-handlable oom as issues, such that we can ensure that we do not fail because of large allocations made by the compiler.