Closed Bug 1296669 Opened 8 years ago Closed 8 years ago

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

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1307651
Tracking Status
firefox51 --- affected

People

(Reporter: decoder, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, bugmon, testcase, Whiteboard: [jsbugmon:update])

The following testcase crashes on mozilla-central revision cf06fbc83175 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug --enable-optimize, run with --fuzzing-safe --ion-eager --ion-offthread-compile=off): function f1(a, bIs, [b] = [3], ...rest) {} assertEq(f1.length, 2); function f2(...each) {} f2(); evaluate(` o = f2(0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9, 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9, 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9, 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9, 0,1,2,3,f2,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9); `); Backtrace: received signal SIGSEGV, Segmentation fault. 0x0000000000cb7cbf in js::LifoAlloc::getOrCreateChunk (this=this@entry=0x7ffff69a8100, n=n@entry=120) at js/src/ds/LifoAlloc.cpp:105 #0 0x0000000000cb7cbf in js::LifoAlloc::getOrCreateChunk (this=this@entry=0x7ffff69a8100, n=n@entry=120) at js/src/ds/LifoAlloc.cpp:105 #1 0x000000000056bd03 in js::LifoAlloc::allocImpl (n=120, this=0x7ffff69a8100) at js/src/ds/LifoAlloc.h:225 #2 js::LifoAlloc::allocInfallible (this=0x7ffff69a8100, n=120) at js/src/ds/LifoAlloc.h:291 #3 0x0000000000748990 in js::jit::TempAllocator::allocateInfallible (bytes=120, this=<optimized out>) at js/src/jit/JitAllocPolicy.h:46 #4 js::jit::TempObject::operator new (alloc=..., nbytes=120) at js/src/jit/JitAllocPolicy.h:247 #5 js::jit::MInstruction::operator new (alloc=..., nbytes=120) at js/src/jit/MIR.h:1046 #6 js::jit::MConstant::New (alloc=..., v=..., constraints=constraints@entry=0x0) at js/src/jit/MIR.cpp:744 #7 0x000000000065ff60 in js::jit::IonBuilder::jsop_rest (this=this@entry=0x7fffffffb1c0) at js/src/jit/IonBuilder.cpp:10774 #8 0x0000000000691b43 in js::jit::IonBuilder::inspectOpcode (this=this@entry=0x7fffffffb1c0, op=op@entry=JSOP_REST) at js/src/jit/IonBuilder.cpp:1788 #9 0x00000000006898d0 in js::jit::IonBuilder::traverseBytecode (this=this@entry=0x7fffffffb1c0) at js/src/jit/IonBuilder.cpp:1540 #10 0x000000000068abcf in js::jit::IonBuilder::buildInline (this=0x7fffffffb1c0, callerBuilder=<optimized out>, callerResumePoint=<optimized out>, callInfo=...) at js/src/jit/IonBuilder.cpp:1096 #11 0x000000000068b059 in js::jit::IonBuilder::inlineScriptedCall (this=this@entry=0x7ffff69cf1d0, callInfo=..., target=<optimized out>) at js/src/jit/IonBuilder.cpp:5231 #12 0x000000000068b600 in js::jit::IonBuilder::inlineSingleCall (this=0x7ffff69cf1d0, callInfo=..., targetArg=<optimized out>) at js/src/jit/IonBuilder.cpp:5739 #13 0x000000000068ce59 in js::jit::IonBuilder::inlineCallsite (this=0x7ffff69cf1d0, targets=..., callInfo=...) at js/src/jit/IonBuilder.cpp:5795 #14 0x000000000068d2e5 in js::jit::IonBuilder::jsop_call (this=this@entry=0x7ffff69cf1d0, argc=100, constructing=<optimized out>) at js/src/jit/IonBuilder.cpp:6736 #15 0x000000000069151c in js::jit::IonBuilder::inspectOpcode (this=this@entry=0x7ffff69cf1d0, op=op@entry=JSOP_CALL) at js/src/jit/IonBuilder.cpp:1923 #16 0x00000000006898d0 in js::jit::IonBuilder::traverseBytecode (this=this@entry=0x7ffff69cf1d0) at js/src/jit/IonBuilder.cpp:1540 #17 0x000000000068a4d5 in js::jit::IonBuilder::build (this=0x7ffff69cf1d0) at js/src/jit/IonBuilder.cpp:924 #18 0x000000000069d7a1 in js::jit::IonCompile (cx=cx@entry=0x7ffff695f000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x0, osrPc=<optimized out>, constructing=<optimized out>, recompile=<optimized out>, optimizationLevel=js::jit::OptimizationLevel::Normal) at js/src/jit/Ion.cpp:2232 #19 0x000000000069e1e9 in js::jit::Compile (cx=cx@entry=0x7ffff695f000, script=script@entry=..., osrFrame=osrFrame@entry=0x0, osrPc=osrPc@entry=0x0, constructing=<optimized out>, forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2464 #20 0x000000000069e3ee in js::jit::CanEnter (cx=cx@entry=0x7ffff695f000, state=...) at js/src/jit/Ion.cpp:2556 [...] #54 0x0000000000000000 in ?? () rax 0x0 0 rbx 0x8000 32768 rcx 0x7ffff6c28a2d 140737333332525 rdx 0x0 0 rsi 0x7ffff6ef7770 140737336276848 rdi 0x7ffff6ef6540 140737336272192 rbp 0x7fffffffade0 140737488334304 rsp 0x7fffffffad20 140737488334112 r8 0x7ffff6ef7770 140737336276848 r9 0x7ffff7fe4740 140737354024768 r10 0x58 88 r11 0x7ffff6b9f750 140737332770640 r12 0x7ffff69d7000 140737330900992 r13 0x7ffff69a8100 140737330708736 r14 0x78 120 r15 0x0 0 rip 0xcb7cbf <js::LifoAlloc::getOrCreateChunk(unsigned long)+847> => 0xcb7cbf <js::LifoAlloc::getOrCreateChunk(unsigned long)+847>: movl $0x0,0x0 0xcb7cca <js::LifoAlloc::getOrCreateChunk(unsigned long)+858>: ud2
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/977e5fd31b3d user: Nicolas B. Pierron date: Tue Jul 05 13:38:18 2016 +0000 summary: Bug 1264948 part 2 - Assert when we allocate new chunks using an infallible allocator. r=jonco,h4writer This iteration took 0.857 seconds to run.
Flags: needinfo?(nicolas.b.pierron)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(nicolas.b.pierron)
You need to log in before you can comment on or make changes to this bug.