1223023 - Assertion failure: result ([OOM] Is it really infallible?), at js/src/ds/LifoAlloc.h:281

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision e2a910c048dc (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-eager --ion-check-range-analysis):

var lfcode = new Array();
setJitCompilerOption('ion.warmup.trigger', 2);
gcPreserveCode()
loadFile(`
oomTest(() => getBacktrace({
    thisprops: gc() && delete addDebuggee.quit
}));
`);
function loadFile(lfVarx) {
  eval(lfVarx);
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5ac2700 (LWP 40536)]
0x000000000058f9a2 in js::LifoAlloc::allocInfallibleOrAssert (this=0x7ffff47fc800, n=n@entry=184) at js/src/ds/LifoAlloc.h:281
#0  0x000000000058f9a2 in js::LifoAlloc::allocInfallibleOrAssert (this=0x7ffff47fc800, n=n@entry=184) at js/src/ds/LifoAlloc.h:281
#1  0x0000000000760745 in allocateInfallible (bytes=184, this=0x7ffff69b5020) at js/src/jit/JitAllocPolicy.h:40
#2  operator new (alloc=..., nbytes=184) at js/src/jit/JitAllocPolicy.h:174
#3  New (alloc=...) at js/src/jit/shared/LIR-shared.h:119
#4  js::jit::RegisterAllocator::getInputMoveGroup (this=this@entry=0x7ffff5ac0e50, ins=ins@entry=0x7ffff69ba2a8) at js/src/jit/RegisterAllocator.cpp:498
#5  0x0000000000beb109 in moveInput (type=js::jit::LDefinition::OBJECT, to=0x7ffff69c5420, from=0x7ffff69c5498, ins=0x7ffff69ba2a8, this=0x7ffff5ac0e50) at js/src/jit/BacktrackingAllocator.h:701
#6  js::jit::BacktrackingAllocator::resolveControlFlow (this=this@entry=0x7ffff5ac0e50) at js/src/jit/BacktrackingAllocator.cpp:1774
#7  0x0000000000bf3e26 in js::jit::BacktrackingAllocator::go (this=this@entry=0x7ffff5ac0e50) at js/src/jit/BacktrackingAllocator.cpp:842
#8  0x000000000068a1d6 in js::jit::GenerateLIR (mir=mir@entry=0x7ffff69b51c0) at js/src/jit/Ion.cpp:1898
#9  0x000000000068d3a5 in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff69b51c0) at js/src/jit/Ion.cpp:1968
#10 0x00000000009d4510 in js::HelperThread::handleIonWorkload (this=this@entry=0x7ffff6933a00) at js/src/vm/HelperThreads.cpp:1293
#11 0x00000000009d5ca7 in js::HelperThread::threadLoop (this=0x7ffff6933a00) at js/src/vm/HelperThreads.cpp:1611
#12 0x0000000000a1eca1 in nspr::Thread::ThreadRoutine (arg=0x7ffff692e180) at js/src/vm/PosixNSPR.cpp:45
#13 0x00007ffff7bc4182 in start_thread (arg=0x7ffff5ac2700) at pthread_create.c:312
#14 0x00007ffff6cb3fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
rax	0x0	0
rbx	0x7ffff69be000	140737330798592
rcx	0x7ffff6ca53cd	140737333842893
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7ffff5ac0920	140737315080480
rsp	0x7ffff5ac08f0	140737315080432
r8	0x7ffff5ac2700	140737315088128
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7ffff5ac06b0	140737315079856
r11	0x7ffff6c27960	140737333328224
r12	0xb8	184
r13	0x7ffff69c5fc0	140737330831296
r14	0x7ffff47fc800	140737295403008
r15	0x7ffff69c6078	140737330831480
rip	0x58f9a2 <js::LifoAlloc::allocInfallibleOrAssert(unsigned long)+242>
=> 0x58f9a2 <js::LifoAlloc::allocInfallibleOrAssert(unsigned long)+242>:	movl   $0x119,0x0
   0x58f9ad <js::LifoAlloc::allocInfallibleOrAssert(unsigned long)+253>:	callq  0x4a6ce0 <abort()>


This could be a dup of bug 1222675 given that it's calling from the BacktrackingAllocator. Even if it is, we should probably see if the test here is more useful.

Comment 1

[Christian Holler (:decoder)]

Needinfo for nbp because he typically looks at these asserts :)

Comment 2

[Fuzzing Team]

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/fbf7d94986bb
parent:      269729:5430b2dba98b
user:        Nicolas B. Pierron
date:        Tue Oct 27 14:50:09 2015 +0000
summary:     Bug 991249 - Ensure that we can check for OOMs when we run out of ballast space. r=jandem

This iteration took 258.160 seconds to run.

Comment 3

[Nicolas B. Pierron [:nbp] {away}]

Attachment: Ensure that we have enough ballast space for allocating MoveGroups in BacktrackingAllocator::resolveControlFlow.

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f2f41c4ca5fa

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f2f41c4ca5fa