1286462 - Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at js/src/ds/LifoAlloc.cpp:105

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

The following testcase crashes on mozilla-central revision 04821a70c739 (build with --enable-debug --enable-more-deterministic, run with --fuzzing-safe --no-threads --baseline-eager):

function g(x) {
    for (var j = 0; j < 23; ++j) {
        for (var k = 0; k < 23; ++k) {
            try {
                mathy4(x[0], x[j]);
            } catch (e) {}
        }
    }
}
mathy0 = function(x, y) {
    (+Math.min, y) + y < Math.fround(Math.fround())
}
mathy1 = function(x, y) {
    !Math.atan2(mathy0(mathy0(x, +y), Math.fround(y ? Math.fround() : Math.fround())), Math.trunc(Math.fround(Math.cosh(Math.fround(x)))) && mathy0()) ? Math.asinh(Math.sqrt) > y || -y : Math.acosh(mathy0(Math.log1p(Math.fround(mathy0(y, x)()()))))
}
mathy2 = function() {
    mathy0(Math.min)
    Math.min
    mathy1(Math.min)
}
mathy4 = function(x, y) {
    Math.min
    Math.min ? Math.min : x
    mathy1(Math.min(y))
    Math.min
    Math.min
    mathy2(Math.min(Math.min))
    Math.min
    Math.min
    Math.min
    Math.min
    mathy2(Math.min, Math.min)
    Math.min
    Math.min
    Math.min
    Math.min - mathy1(x / 0x0ffffffff, x)
}
g(Math.PI)
mathy2 = function() Math.tan(Math.atan2(Math.abs(x > Math.PI))) % Math.sign
mathy0 = function(x, y) {
    return ((y ? -Number.MAX_VALUE : Math.fround(Math.fround(Math.cosh()) != 0x080000001 != y) !== !x ? (Math.min(Math.atan2(y, Number.MIN_VALUE), x) && Math.fround(y) / Math.sinh(Math.fround + Math.sin())) == y : Math.fround()) >= Math.fround(Math.hypot(Math.fround(y - +y >>> 0 << (0x100000001 !== x) >>> 0 >>> 0 <= Math.acosh()), Math.fround + Math.tanh(- +y >>> 0 == Math.fround(Math.max(+x, Math.fround(y)))) <= (x | 0 | Math.sqrt(Math.fround(Math.log10(y))) | 0 | 0) >>> 0)))
}
g([-0x080000001])


Backtrace:

0   js-dbg-64-dm-clang-darwin-04821a70c739	0x0000000110593b34 js::LifoAlloc::getOrCreateChunk(unsigned long) + 356 (LifoAlloc.cpp:105)
1   js-dbg-64-dm-clang-darwin-04821a70c739	0x0000000110360ae7 js::LifoAlloc::allocImpl(unsigned long) + 103 (LifoAlloc.h:225)
2   js-dbg-64-dm-clang-darwin-04821a70c739	0x00000001100f0b92 js::jit::TempAllocator::allocateInfallible(unsigned long) + 130 (LifoAlloc.h:291)
3   js-dbg-64-dm-clang-darwin-04821a70c739	0x000000010fefb49b js::jit::MSqrt::trySpecializeFloat32(js::jit::TempAllocator&) + 235 (JitAllocPolicy.h:161)
4   js-dbg-64-dm-clang-darwin-04821a70c739	0x000000010fde4504 js::jit::ApplyTypeInformation(js::jit::MIRGenerator*, js::jit::MIRGraph&) + 2260 (IonAnalysis.cpp:1821)
5   js-dbg-64-dm-clang-darwin-04821a70c739	0x000000010fddc3b0 js::jit::OptimizeMIR(js::jit::MIRGenerator*) + 1744 (Ion.cpp:1614)
6   js-dbg-64-dm-clang-darwin-04821a70c739	0x000000010fde84b3 js::jit::CompileBackEnd(js::jit::MIRGenerator*) + 67 (Ion.cpp:2012)
/snip

For detailed crash information, see attachment.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Detailed Crash Information

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160705060723" and the hash "359a15f3afea99a3422bc03d5b699c6f93aa9a94".
The "bad" changeset has the timestamp "20160705063922" and the hash "977e5fd31b3d8f83e3c6b4560f6784fbabdbf49a".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=359a15f3afea99a3422bc03d5b699c6f93aa9a94&tochange=977e5fd31b3d8f83e3c6b4560f6784fbabdbf49a

Nicolas, is bug 1264948 a likely regressor?

(Note that this testcase can be slightly intermittent)

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #2)
> Nicolas, is bug 1264948 a likely regressor?

Yes, this assertion is always for me (ni? me), these are usually easy to fix with a stack trace.

Having a test case is better, as it help me to verify that the issue does not reproduce after, but the complexity of the test case should not matter as long as it reproduces.

Comment 4

[Nicolas B. Pierron [:nbp]]

Attachment: Ensure we have enough ballast space in TypeAnalyzer::specializeValidFloatOps.

Comment 5

[Benjamin Bouvier [:bbouvier] (inactive)]

Comment on attachment 8770518 [details] [diff] [review]
Ensure we have enough ballast space in TypeAnalyzer::specializeValidFloatOps.

Review of attachment 8770518 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3cf91a31e92c
Ensure we have enough ballast space in TypeAnalyzer::specializeValidFloatOps. r=bbouvier

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3cf91a31e92c