Closed Bug 1491353 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:142

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox-esr60 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- fixed

People

(Reporter: decoder, Assigned: nbp)

References

Details

(4 keywords, Whiteboard: [jsbugmon:update])

Attachments

(1 file)

The following testcase crashes on mozilla-central revision efccb758c78c (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-eager): setJitCompilerOption("baseline.warmup.trigger", 2); var g = newGlobal(); function test1(code) { g.eval(code); } var manyNames = ''; for (var i = 0; i < 2048; i++) manyNames += 'x' + i + ', '; manyNames += 'X'; function test2(code) { test1(code.replace('@@', manyNames)); } test2('function f() { for (let @@ = 0; X < 1; X++) h(); } f();'); Backtrace: received signal SIGSEGV, Segmentation fault. 0x00005555560f15b0 in js::LifoAlloc::newChunkWithCapacity (this=this@entry=0x7ffff483de20, n=n@entry=16) at js/src/ds/LifoAlloc.cpp:142 #0 0x00005555560f15b0 in js::LifoAlloc::newChunkWithCapacity (this=this@entry=0x7ffff483de20, n=n@entry=16) at js/src/ds/LifoAlloc.cpp:142 #1 0x00005555560f6dd3 in js::LifoAlloc::getOrCreateChunk (this=this@entry=0x7ffff483de20, n=n@entry=16) at js/src/ds/LifoAlloc.cpp:192 #2 0x0000555555754f8b in js::LifoAlloc::allocImpl (n=16, this=0x7ffff483de20) at js/src/ds/LifoAlloc.h:584 #3 js::LifoAlloc::alloc (this=this@entry=0x7ffff483de20, n=n@entry=16) at js/src/ds/LifoAlloc.h:651 #4 0x00005555559dadd6 in js::LifoAlloc::new_<js::TemporaryTypeSet, js::LifoAlloc*&, js::TypeSet::Type&> (this=0x7ffff483de20) at js/src/ds/LifoAlloc.h:866 #5 js::jit::IonBuilder::newPendingLoopHeader (this=this@entry=0x7ffff48d10d0, predecessor=<optimized out>, pc=<optimized out>, osr=osr@entry=true, canOsr=<optimized out>, stackPhiCount=<optimized out>) at js/src/jit/IonBuilder.cpp:7273 #6 0x0000555555a16602 in js::jit::IonBuilder::visitLoopEntry (this=this@entry=0x7ffff48d10d0, loopEntry=0x7ffff480f140) at js/src/jit/IonBuilder.cpp:1820 #7 0x0000555555a16aa3 in js::jit::IonBuilder::visitControlInstruction (this=this@entry=0x7ffff48d10d0, ins=0x7ffff480f140, restarted=restarted@entry=0x7fffffff6377) at js/src/jit/IonBuilder.cpp:1876 #8 0x0000555555a30c7a in js::jit::IonBuilder::traverseBytecode (this=this@entry=0x7ffff48d10d0) at js/src/jit/IonBuilder.cpp:1569 #9 0x0000555555a31a12 in js::jit::IonBuilder::build (this=this@entry=0x7ffff48d10d0) at js/src/jit/IonBuilder.cpp:908 #10 0x0000555555a3e661 in js::jit::IonCompile (cx=<optimized out>, cx@entry=0x7ffff5f16000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x7fffffffa898, osrPc=osrPc@entry=0x7ffff4c2b048 "\343\201V>\001", recompile=<optimized out>, optimizationLevel=<optimized out>) at js/src/jit/Ion.cpp:2136 #11 0x0000555555a3f30d in js::jit::Compile (cx=cx@entry=0x7ffff5f16000, script=script@entry=..., osrFrame=osrFrame@entry=0x7fffffffa898, osrPc=osrPc@entry=0x7ffff4c2b048 "\343\201V>\001", forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2437 #12 0x0000555555a3fa7c in BaselineCanEnterAtBranch (pc=0x7ffff4c2b048 "\343\201V>\001", osrFrame=0x7fffffffa898, script=..., cx=0x7ffff5f16000) at js/src/jit/Ion.cpp:2630 #13 js::jit::IonCompileScriptForBaseline (cx=<optimized out>, frame=frame@entry=0x7fffffffa898, pc=pc@entry=0x7ffff4c2b048 "\343\201V>\001") at js/src/jit/Ion.cpp:2692 #14 0x00005555559087b2 in js::jit::DoWarmUpCounterFallbackOSR (cx=<optimized out>, frame=0x7fffffffa898, stub=0x7ffff493f178, infoPtr=0x7fffffff6868) at js/src/jit/BaselineIC.cpp:432 #15 0x00003c1c7d266a1d in ?? () [...] #25 0x0000000000000000 in ?? () rax 0x0 0 rbx 0x7ffff483de20 140737295670816 rcx 0x7ffff6c1c2dd 140737333281501 rdx 0x0 0 rsi 0x7ffff6eeb770 140737336227696 rdi 0x7ffff6eea540 140737336223040 rbp 0x7fffffff6180 140737488314752 rsp 0x7fffffff6160 140737488314720 r8 0x7ffff6eeb770 140737336227696 r9 0x7ffff7fe6780 140737354033024 r10 0x58 88 r11 0x7ffff6b927a0 140737332717472 r12 0x10 16 r13 0x7fffffff61a0 140737488314784 r14 0x7fffe25ead40 140736991243584 r15 0x7fffe27e8fb0 140736993333168 rip 0x5555560f15b0 <js::LifoAlloc::newChunkWithCapacity(unsigned long)+208> => 0x5555560f15b0 <js::LifoAlloc::newChunkWithCapacity(unsigned long)+208>: movl $0x0,0x0 0x5555560f15bb <js::LifoAlloc::newChunkWithCapacity(unsigned long)+219>: 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/73e1760e3c4d user: Jan de Mooij date: Thu Oct 15 16:20:29 2015 +0200 summary: Bug 1214562 part 2 - Refactor SetPropertyCache regalloc. r=bhackett This iteration took 242.269 seconds to run.
Jan, is bug 1214562 a likely regressor?
Blocks: 1214562
Flags: needinfo?(jdemooij)
It's likely unrelated. Nicolas, do you mind looking at this LifoAlloc/OOM issue?
Flags: needinfo?(jdemooij) → needinfo?(nicolas.b.pierron)
Attachment #9010325 - Flags: review?(jitbugs) → review+
Assignee: nobody → nicolas.b.pierron
Status: NEW → ASSIGNED
Flags: needinfo?(nicolas.b.pierron)
Pushed by npierron@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/dce559a7ac35 Make the allocator fallible to work-around false positive uncatchable OOMs. r=mgaudet
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: