The following testcase crashes on mozilla-central revision 2ddec2dedced (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 --arm-hwcap=vfp): oomTest(((function() { try { gczeal(2)(uneval(this)) } catch(e) {} }))); function oomTest(f) { var i = 1; do { try { oomAtAllocation(i); f(); } catch (e) {} more = resetOOMFailure(); i++; } while(more); } Backtrace: Program received signal SIGSEGV, Segmentation fault. mozilla::PodCopy<int> (aDst=0x0, aSrc=0xf7a9c090, aNElem=7) at ../../dist/include/mozilla/PodOperations.h:107 #0 mozilla::PodCopy<int> (aDst=0x0, aSrc=0xf7a9c090, aNElem=7) at ../../dist/include/mozilla/PodOperations.h:107 #1 0x086d2f3d in insertEntry (lifoAlloc=..., off=..., data=0xffffa4ec "4\"\240", <incomplete sequence \367>, num=1, this=0xffffac08) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:225 #2 js::jit::AssemblerBufferWithConstantPools<1024u, 4u, js::jit::Instruction, js::jit::Assembler>::insertEntryForwards (this=this@entry=0xffffabb8, numInst=numInst@entry=1, numPoolEntries=numPoolEntries@entry=1, inst=inst@entry=0xffffa4c0 "", data=data@entry=0xffffa4ec "4\"\240", <incomplete sequence \367>) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:555 #3 0x086904ce in js::jit::AssemblerBufferWithConstantPools<1024u, 4u, js::jit::Instruction, js::jit::Assembler>::allocEntry (this=this@entry=0xffffabb8, inst=inst@entry=0xffffa4c0 "", data=data@entry=0xffffa4ec "4\"\240", <incomplete sequence \367>, pe=pe@entry=0x0, markAsBranch=markAsBranch@entry=false, numPoolEntries=1, numInst=1) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:592 #4 0x086906f8 in js::jit::Assembler::as_Imm32Pool (this=this@entry=0xffffa9bc, dest=dest@entry=..., value=value@entry=4154466868, c=c@entry=js::jit::Assembler::Always) at js/src/jit/arm/Assembler-arm.cpp:1815 #5 0x08697a4b in js::jit::MacroAssemblerARM::ma_movPatchable (this=0xffffa9bc, imm_=imm_@entry=..., dest=dest@entry=..., c=c@entry=js::jit::Assembler::Always, rs=js::jit::Assembler::L_LDR) at js/src/jit/arm/MacroAssembler-arm.cpp:446 #6 0x08698067 in ma_movPatchable (rs=<optimized out>, c=js::jit::Assembler::Always, dest=..., imm=..., this=0xffffa9bc) at js/src/jit/arm/MacroAssembler-arm.cpp:455 #7 js::jit::MacroAssemblerARM::ma_call (this=this@entry=0xffffa9bc, dest=dest@entry=...) at js/src/jit/arm/MacroAssembler-arm.cpp:3705 #8 0x086adea4 in js::jit::MacroAssemblerARMCompat::callWithABI (this=this@entry=0xffffa9bc, fun=0xf7a02234, fun@entry=0x85bd2c0 <AssumeUnreachable_(char const*)>, result=result@entry=js::jit::MoveOp::GENERAL) at js/src/jit/arm/MacroAssembler-arm.cpp:4116 #9 0x0862201d in callWithABI<void*> (result=js::jit::MoveOp::GENERAL, fun=<optimized out>, this=0xffffa9bc) at js/src/jit/MacroAssembler.h:1008 #10 js::jit::MacroAssembler::assumeUnreachable (this=this@entry=0xffffa9bc, output=output@entry=0x8b2ac68 "BaselineFrame shouldn't override pc when executing JIT code") at js/src/jit/MacroAssembler.cpp:1806 #11 0x0871f5b5 in js::jit::BaselineCompilerShared::callVM (this=this@entry=0xffffa9b0, fun=..., phase=js::jit::BaselineCompilerShared::POST_INITIALIZE) at js/src/jit/shared/BaselineCompiler-shared.cpp:74 #12 0x084a2e8b in callVMNonOp (phase=<optimized out>, fun=..., this=0xffffa9b0) at js/src/jit/shared/BaselineCompiler-shared.h:154 #13 js::jit::BaselineCompiler::emitStackCheck (this=this@entry=0xffffa9b0, earlyCheck=earlyCheck@entry=false) at js/src/jit/BaselineCompiler.cpp:573 #14 0x084ce5e8 in js::jit::BaselineCompiler::emitPrologue (this=this@entry=0xffffa9b0) at js/src/jit/BaselineCompiler.cpp:430 #15 0x084f539b in js::jit::BaselineCompiler::compile (this=this@entry=0xffffa9b0) at js/src/jit/BaselineCompiler.cpp:98 #16 0x084f691e in js::jit::BaselineCompile (cx=cx@entry=0xf7a20200, script=0xf574b160, forceDebugInstrumentation=false) at js/src/jit/BaselineJIT.cpp:263 #17 0x084f7051 in CanEnterBaselineJIT (cx=cx@entry=0xf7a20200, script=..., script@entry=..., osrFrame=osrFrame@entry=0x0) at js/src/jit/BaselineJIT.cpp:302 #18 0x084f7427 in js::jit::CanEnterBaselineMethod (cx=cx@entry=0xf7a20200, state=...) at js/src/jit/BaselineJIT.cpp:370 #19 0x082ef32f in js::RunScript (cx=cx@entry=0xf7a20200, state=...) at js/src/vm/Interpreter.cpp:647 #20 0x082efb7c in js::Invoke (cx=cx@entry=0xf7a20200, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:738 #21 0x082f0c13 in js::Invoke (cx=cx@entry=0xf7a20200, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0xf59ffec8, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:775 #22 0x084f1c6e in js::jit::DoCallFallback (cx=cx@entry=0xf7a20200, frame=frame@entry=0xf59ffef8, stub_=stub_@entry=0xf7a21110, argc=argc@entry=0, vp=vp@entry=0xf59ffeb8, res=res@entry=...) at js/src/jit/BaselineIC.cpp:9859 #23 0x08735756 in js::jit::Simulator::softwareInterrupt (this=0xf7a7f000, instr=0xf7a02e04) at js/src/jit/arm/Simulator-arm.cpp:2171 #24 0x08735986 in js::jit::Simulator::decodeType7 (this=0xf7a7f000, instr=0xf7a02e04) at js/src/jit/arm/Simulator-arm.cpp:3270 #25 0x08733c25 in js::jit::Simulator::instructionDecode (this=this@entry=0xf7a7f000, instr=instr@entry=0xf7a02e04) at js/src/jit/arm/Simulator-arm.cpp:4189 #26 0x087374fc in execute<false> (this=0xf7a7f000) at js/src/jit/arm/Simulator-arm.cpp:4244 #27 js::jit::Simulator::callInternal (this=this@entry=0xf7a7f000, entry=entry@entry=0xf7fc8a30 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>) at js/src/jit/arm/Simulator-arm.cpp:4332 #28 0x08737981 in js::jit::Simulator::call (this=<optimized out>, entry=entry@entry=0xf7fc8a30 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>, argument_count=<optimized out>, argument_count@entry=8) at js/src/jit/arm/Simulator-arm.cpp:4415 #29 0x0846a4b9 in EnterBaseline (cx=cx@entry=0xf7a20200, data=...) at js/src/jit/BaselineJIT.cpp:124 #30 0x084dc469 in js::jit::EnterBaselineAtBranch (cx=0xf7a20200, fp=0xf56c1080, pc=0xf7a89a11 "う\232") at js/src/jit/BaselineJIT.cpp:228 #31 0x082ee161 in Interpret (cx=cx@entry=0xf7a20200, state=...) at js/src/vm/Interpreter.cpp:2031 #32 0x082ef249 in js::RunScript (cx=cx@entry=0xf7a20200, state=...) at js/src/vm/Interpreter.cpp:661 #33 0x082f9505 in js::ExecuteKernel (cx=cx@entry=0xf7a20200, script=..., script@entry=..., scopeChainArg=..., thisv=..., newTargetValue=..., type=type@entry=js::EXECUTE_GLOBAL, evalInFrame=evalInFrame@entry=..., result=result@entry=0x0) at js/src/vm/Interpreter.cpp:902 #34 0x082f9920 in js::Execute (cx=cx@entry=0xf7a20200, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0x0) at js/src/vm/Interpreter.cpp:936 #35 0x0872fe04 in ExecuteScript (cx=cx@entry=0xf7a20200, scope=..., script=script@entry=..., rval=rval@entry=0x0) at js/src/jsapi.cpp:4334 #36 0x0872fff6 in JS_ExecuteScript (cx=cx@entry=0xf7a20200, scriptArg=scriptArg@entry=...) at js/src/jsapi.cpp:4365 #37 0x0806b499 in RunFile (compileOnly=false, file=0xf7ae59e0, filename=0xffffd0b4 "min.js", cx=0xf7a20200) at js/src/shell/js.cpp:458 #38 Process (cx=cx@entry=0xf7a20200, filename=0xffffd0b4 "min.js", forceTTY=forceTTY@entry=false) at js/src/shell/js.cpp:576 #39 0x080cac70 in ProcessArgs (op=0xffffcd60, cx=<optimized out>) at js/src/shell/js.cpp:5771 #40 Shell (envp=<optimized out>, op=0xffffcd60, cx=<optimized out>) at js/src/shell/js.cpp:6040 #41 main (argc=5, argv=0xffffceb4, envp=0xffffcecc) at js/src/shell/js.cpp:6384 eax 0x0 0 ebx 0x9749434 158635060 ecx 0xf7a9c098 -139870056 edx 0xf7a290d0 -140341040 esi 0x4 4 edi 0xf7a9c094 -139870060 ebp 0xffffa3f8 4294943736 esp 0xffffa3d0 4294943696 eip 0x866a2e0 <mozilla::PodCopy<int>(int*, int const*, size_t)+128> => 0x866a2e0 <mozilla::PodCopy<int>(int*, int const*, size_t)+128>: mov %edx,(%eax) 0x866a2e2 <mozilla::PodCopy<int>(int*, int const*, size_t)+130>: jbe 0x866a2f8 <mozilla::PodCopy<int>(int*, int const*, size_t)+152> This is likely a null-deref, so not marking s-s.

Missing null pointer check, easy fix.

Attempts to guard against and propagate OOM within the buffer code, and then capture it at the call site. ARM64 will need the similar capture fix, I will file a separate bug.

Grumble. I'm now running into occasional assertions in CallJSNative where cx->isExceptionPending is set but the native function did not return false. Presumably the OOM flag is not being picked up everywhere it needs to be.

(In reply to Lars T Hansen [:lth] from comment #3) > Grumble. I'm now running into occasional assertions in CallJSNative where > cx->isExceptionPending is set but the native function did not return false. > Presumably the OOM flag is not being picked up everywhere it needs to be. This is a bug in the HashTable code, it drops an OOM condition on the floor in checkUnderloaded(). It either needs to propagate that - looks hairy and maybe pointless - or it needs to reset the exception. Will file a bug for that; can't land this until that's been fixed.

(In reply to Lars T Hansen [:lth] from comment #4) > This is a bug in the HashTable code, it drops an OOM condition on the floor > in checkUnderloaded(). I filed bug 1207519 for that this morning.

(In reply to Jon Coppeard (:jonco) from comment #5) > (In reply to Lars T Hansen [:lth] from comment #4) > > This is a bug in the HashTable code, it drops an OOM condition on the floor > > in checkUnderloaded(). > > I filed bug 1207519 for that this morning. Most excellent.

https://hg.mozilla.org/integration/mozilla-inbound/rev/10db467779a053321e9f4a0e6ee8079ddc480752 Bug 1186982 - check for allocation failure. r=h4writer

Backed out for SM orange: https://treeherder.mozilla.org/logviewer.html#?job_id=14974498&repo=mozilla-inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/8799f0dcfe76

(In reply to Wes Kocher (:KWierso) from comment #8) > Backed out for SM orange: > https://treeherder.mozilla.org/logviewer.html#?job_id=14974498&repo=mozilla- > inbound > > https://hg.mozilla.org/integration/mozilla-inbound/rev/8799f0dcfe76 Noted.

It looks like all the failures are with --ion-eager --ion-offthread-compile=off. This suggests that there can be OOM failures at locations where the test case may not be prepared to handle them, so this could just be the test cases needing work. For example, in the present test case, wrapping a try/catch around the do-while loop gets rid of the crash. (ni? jonco because of relevance to bug 1209001, decoder because this problem will show up elsewhere too, given the fuzzing pattern that's being used.)

https://hg.mozilla.org/integration/mozilla-inbound/rev/212f49a401b2fe47c6f46c774a214063f2f21246 Bug 1186982 - propagate OOM failures. r=h4writer

Back out for SM failures: https://hg.mozilla.org/integration/mozilla-inbound/rev/21ac28a08b35 https://treeherder.mozilla.org/logviewer.html#?job_id=15003926&repo=mozilla-inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/bc20a0abec612f7cdb6ce52b6393f7d4232c32f8 Bug 1186982 - propagate OOM failures (no test case). r=h4writer

(In reply to Lars T Hansen [:lth] from comment #10) > This suggests that there can be OOM failures > at locations where the test case may not be prepared to handle them Yes, an issue like this came up before in bug 1203814. The original oomTest() function has been fixed but the fuzzers still come up with test cases involving the old one. I tried changing the test code to |load(libdir + 'oomTest.js')| and use the fixed version however there are still failures.

Perhaps this test case can be committed now that we have fixed all the OOM bugs?

(In reply to Jakob Stoklund Olesen [:jolesen] from comment #16) > Perhaps this test case can be committed now that we have fixed all the OOM > bugs? "all the OOM bugs" :) Filed the landing of the TC separately as bug 1215090, as the problem had to do with sporadic failures, needs thorough vetting.