Closed Bug 1491353 Opened 11 months ago Closed 11 months 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, critical)

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

(Blocks 2 open bugs)

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)
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
https://hg.mozilla.org/mozilla-central/rev/dce559a7ac35
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in before you can comment on or make changes to this bug.