1177922 - Assertion failure: offset - safepointIndices_.back().displacement() >= sizeof(uint32_t), at js/src/jit/shared/CodeGenerator-shared.cpp:1006 with OOM

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision bbc26cc168c7 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-simulator=arm --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-check-range-analysis --ion-eager --arm-asm-nop-fill=1 --ion-extra-checks):

function oomTest(f) {
    var i = 1;
    var more;
    do {
      try { oomAtAllocation(i); } catch(exc1) {}
    } while(more);
}
evaluate("oomTest(function() {});", { noScriptRval : true, compileAndGo : true });



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf731db40 (LWP 10024)]
0x086e7d92 in js::jit::CodeGeneratorShared::markSafepointAt (this=0xf7ab6000, offset=1028, ins=0xf7aafd60) at js/src/jit/shared/CodeGenerator-shared.cpp:1005
#0  0x086e7d92 in js::jit::CodeGeneratorShared::markSafepointAt (this=0xf7ab6000, offset=1028, ins=0xf7aafd60) at js/src/jit/shared/CodeGenerator-shared.cpp:1005
#1  0x086f1842 in js::jit::CodeGeneratorShared::callVM (this=this@entry=0xf7ab6000, fun=..., ins=ins@entry=0xf7aafd60, dynStack=dynStack@entry=0x0) at js/src/jit/shared/CodeGenerator-shared.cpp:1312
#2  0x0845fb37 in js::jit::CodeGenerator::emitCallInvokeFunction (this=this@entry=0xf7ab6000, call=call@entry=0xf7aafd60, calleereg=..., calleereg@entry=..., constructing=false, argc=argc@entry=1, unusedStack=unusedStack@entry=104) at js/src/jit/CodeGenerator.cpp:3002
#3  0x0846a6c3 in js::jit::CodeGenerator::visitCallGeneric (this=0xf7ab6000, call=0xf7aafd60) at js/src/jit/CodeGenerator.cpp:3085
#4  0x08602469 in js::jit::LCallGeneric::accept (this=0xf7aafd60, visitor=0xf7ab6000) at js/src/jit/LIR-Common.h:1533
#5  0x084c0ac3 in js::jit::CodeGenerator::generateBody (this=this@entry=0xf7ab6000) at js/src/jit/CodeGenerator.cpp:4106
#6  0x084c1258 in js::jit::CodeGenerator::generate (this=this@entry=0xf7ab6000) at js/src/jit/CodeGenerator.cpp:7782
#7  0x084ea94c in js::jit::GenerateCode (mir=mir@entry=0xf7aae0f8, lir=0xf7aaf308) at js/src/jit/Ion.cpp:1765
#8  0x08543e90 in js::jit::CompileBackEnd (mir=0xf7aae0f8) at js/src/jit/Ion.cpp:1787
#9  0x082913f7 in js::HelperThread::handleIonWorkload (this=this@entry=0xf7a3bc8c) at js/src/vm/HelperThreads.cpp:1127
#10 0x08292bcf in js::HelperThread::threadLoop (this=0xf7a3bc8c) at js/src/vm/HelperThreads.cpp:1423
#11 0x0827d181 in nspr::Thread::ThreadRoutine (arg=0xf7a011a0) at js/src/vm/PosixNSPR.cpp:45
#12 0xf7f9cf70 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#13 0xf7d67bee in clone () from /lib/i386-linux-gnu/libc.so.6
eax	0x0	0
ebx	0x96769c0	157772224
ecx	0xf7e2788c	-136152948
edx	0x0	0
esi	0xf7ab6000	-139763712
edi	0xf7ab6000	-139763712
ebp	0xf731cec8	4147236552
esp	0xf731ce80	4147236480
eip	0x86e7d92 <js::jit::CodeGeneratorShared::markSafepointAt(unsigned int, js::jit::LInstruction*)+610>
=> 0x86e7d92 <js::jit::CodeGeneratorShared::markSafepointAt(unsigned int, js::jit::LInstruction*)+610>:	movl   $0x3ee,0x0
   0x86e7d9c <js::jit::CodeGeneratorShared::markSafepointAt(unsigned int, js::jit::LInstruction*)+620>:	call   0x80eab90 <abort()>


This is a thread race. In order to reproduce the issue, please run the test at least a 100 times. You might get multiple "unhandlable oom" asserts due to thread scheduling, but you should also get the mentioned assertion and possibly other asserts and crashes while running. This is probably one example where an oomAfterAllocation per thread would help making the test case stable.

Comment 1

[Christian Holler (:decoder)]

Jandem, can you maybe take a look at this or find someone who will? This assert and some others are showing up a lot in our fuzzing but we never get reliable testcases for them.

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 3

[Jan de Mooij [:jandem]]

Attachment: Patch

The assert is only valid if we didn't OOM while generating code. If we OOM, the compilation will abort later so we can safely ignore the assert in that case.

Comment 4

[Nicolas B. Pierron [:nbp]]

Comment on attachment 8627458 [details] [diff] [review]
Patch

Review of attachment 8627458 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the delay.

Comment 5

[Pulsebot]

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

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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