Closed
Bug 1286462
Opened 7 years ago
Closed 7 years ago
Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at js/src/ds/LifoAlloc.cpp:105
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla50
Tracking | Status | |
---|---|---|
firefox50 | --- | fixed |
People
(Reporter: gkw, Assigned: nbp)
References
Details
(Keywords: assertion, testcase, Whiteboard: [jsbugmon:update])
Attachments
(2 files)
32.36 KB,
text/plain
|
Details | |
951 bytes,
patch
|
bbouvier
:
review+
|
Details | Diff | Splinter Review |
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.
![]() |
Reporter | |
Comment 1•7 years ago
|
||
![]() |
Reporter | |
Comment 2•7 years ago
|
||
=== 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)
Blocks: 1264948
Flags: needinfo?(nicolas.b.pierron)
Assignee | ||
Comment 3•7 years ago
|
||
(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.
Assignee: nobody → nicolas.b.pierron
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•7 years ago
|
||
Attachment #8770518 -
Flags: review?(bbouvier)
Comment 5•7 years ago
|
||
Comment on attachment 8770518 [details] [diff] [review] Ensure we have enough ballast space in TypeAnalyzer::specializeValidFloatOps. Review of attachment 8770518 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!
Attachment #8770518 -
Flags: review?(bbouvier) → review+
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(nicolas.b.pierron)
Pushed by npierron@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/3cf91a31e92c Ensure we have enough ballast space in TypeAnalyzer::specializeValidFloatOps. r=bbouvier
Comment 7•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3cf91a31e92c
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in
before you can comment on or make changes to this bug.
Description
•