The following testcase crashes on mozilla-central revision c2256ee8ae9a (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 --baseline-eager --arm-asm-nop-fill=1): gTestcases = Array(); gTc = 0; function TestCase() { this.passed = getTestCaseResult(); gTestcases[gTc++] = this; } function getTestCaseResult() {} function test() { for (gTc = 0; gTc < 1; gTc++) try { 0(gTestcases[0].description + "" + gTestcases[gTc].actual); gTestcases[gTc].reason = gTestcases[gTc].passed ? "" : ""; } catch (e) {} } new TestCase(); test(); enableSPSProfilingWithSlowAssertions(); function arrayProtoOutOfRange() test() oomTest(arrayProtoOutOfRange) Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x083014dd in js::jit::AnalyzeNewScriptDefiniteProperties (cx=cx@entry=0xf7a84020, fun=0xf4364a20, group=group@entry=0xf434d3b8, baseobj=baseobj@entry=..., initializerList=initializerList@entry=0xffffaef0) at js/src/jit/IonAnalysis.cpp:3700 #0 0x083014dd in js::jit::AnalyzeNewScriptDefiniteProperties (cx=cx@entry=0xf7a84020, fun=0xf4364a20, group=group@entry=0xf434d3b8, baseobj=baseobj@entry=..., initializerList=initializerList@entry=0xffffaef0) at js/src/jit/IonAnalysis.cpp:3700 #1 0x087d2b47 in js::TypeNewScript::maybeAnalyze (this=0xf41ccda0, cx=cx@entry=0xf7a84020, group=group@entry=0xf434d3b8, regenerate=regenerate@entry=0x0, force=force@entry=true) at js/src/vm/TypeInference.cpp:3736 #2 0x08313a62 in js::jit::IonCompile (cx=cx@entry=0xf7a84020, script=script@entry=0xf4355280, baselineFrame=baselineFrame@entry=0xf45ffdb8, osrPc=osrPc@entry=0x0, constructing=constructing@entry=false, recompile=recompile@entry=false, optimizationLevel=js::jit::Normal) at js/src/jit/Ion.cpp:2224 #3 0x08313fc3 in js::jit::Compile (cx=cx@entry=0xf7a84020, script=script@entry=..., osrFrame=osrFrame@entry=0xf45ffdb8, osrPc=osrPc@entry=0x0, constructing=false, forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2449 #4 0x083148a9 in BaselineCanEnterAtEntry (frame=0xf45ffdb8, script=..., cx=0xf7a84020) at js/src/jit/Ion.cpp:2573 #5 js::jit::IonCompileScriptForBaseline (cx=cx@entry=0xf7a84020, frame=frame@entry=0xf45ffdb8, pc=pc@entry=0xf7ad3aec <incomplete sequence \326>) at js/src/jit/Ion.cpp:2697 #6 0x084fe483 in js::jit::Simulator::softwareInterrupt (this=0xf7a83000, instr=0xf7a02b84) at js/src/jit/arm/Simulator-arm.cpp:2339 #7 0x084fea06 in js::jit::Simulator::decodeType7 (this=0xf7a83000, instr=0xf7a02b84) at js/src/jit/arm/Simulator-arm.cpp:3482 #8 0x084fc9c5 in js::jit::Simulator::instructionDecode (this=this@entry=0xf7a83000, instr=instr@entry=0xf7a02b84) at js/src/jit/arm/Simulator-arm.cpp:4404 #9 0x085007ec in execute<false> (this=0xf7a83000) at js/src/jit/arm/Simulator-arm.cpp:4459 #10 js::jit::Simulator::callInternal (this=this@entry=0xf7a83000, entry=entry@entry=0xf7fc91f8 "\377\377\377\352\360O-\351\377\377\377\352\004\320M\342\377\377\377\352\020\212-\355\377\377\377\352\r\200\240\341\377\377\377\352h\220\235\345\377\377\377\352t\240\235\345\377\377\377", <incomplete sequence \352>) at js/src/jit/arm/Simulator-arm.cpp:4547 #11 0x08500d05 in js::jit::Simulator::call (this=<optimized out>, entry=entry@entry=0xf7fc91f8 "\377\377\377\352\360O-\351\377\377\377\352\004\320M\342\377\377\377\352\020\212-\355\377\377\377\352\r\200\240\341\377\377\377\352h\220\235\345\377\377\377\352t\240\235\345\377\377\377", <incomplete sequence \352>, argument_count=<optimized out>, argument_count@entry=8) at js/src/jit/arm/Simulator-arm.cpp:4630 #12 0x0830a911 in EnterIon (data=..., cx=0xf7a84020) at js/src/jit/Ion.cpp:2808 #13 js::jit::IonCannon (cx=cx@entry=0xf7a84020, state=...) at js/src/jit/Ion.cpp:2903 #14 0x086bcf1f in js::RunScript (cx=cx@entry=0xf7a84020, state=...) at js/src/vm/Interpreter.cpp:405 #15 0x086bd18e in js::Invoke (cx=0xf7a84020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:493 #16 0x086bdc5e in js::Invoke (cx=cx@entry=0xf7a84020, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0x0, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:527 #17 0x085193b8 in JS_CallFunction (cx=cx@entry=0xf7a84020, obj=..., fun=fun@entry=..., args=..., rval=rval@entry=...) at js/src/jsapi.cpp:2848 #18 0x086e468a in OOMTest (cx=0xf7a84020, argc=1, vp=0xffffbbe0) at js/src/builtin/TestingFunctions.cpp:1202 #19 0x086c344a in js::CallJSNative (cx=0xf7a84020, native=0x86e4390 <OOMTest(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235 [...] #40 main (argc=4, argv=0xffffcbf4, envp=0xffffcc08) at js/src/shell/js.cpp:6999 eax 0x0 0 ebx 0x9816438 159474744 ecx 0xf7e3b88c -136071028 edx 0x0 0 esi 0x0 0 edi 0xf7a84020 -139968480 ebp 0xffffae58 4294946392 esp 0xffffa710 4294944528 eip 0x83014dd <js::jit::AnalyzeNewScriptDefiniteProperties(JSContext*, JSFunction*, js::ObjectGroup*, JS::Handle<js::PlainObject*>, mozilla::Vector<js::TypeNewScript::Initializer, 0u, js::TempAllocPolicy>*)+1965> => 0x83014dd <js::jit::AnalyzeNewScriptDefiniteProperties(JSContext*, JSFunction*, js::ObjectGroup*, JS::Handle<js::PlainObject*>, mozilla::Vector<js::TypeNewScript::Initializer, 0u, js::TempAllocPolicy>*)+1965>: movl $0xe74,0x0 0x83014e7 <js::jit::AnalyzeNewScriptDefiniteProperties(JSContext*, JSFunction*, js::ObjectGroup*, JS::Handle<js::PlainObject*>, mozilla::Vector<js::TypeNewScript::Initializer, 0u, js::TempAllocPolicy>*)+1975>: call 0x80f9100 <abort()>

This is one place where the callee sets an OOM exception, and there are plenty of ways this can happen in the IonBuilder.build() function. It seems a bit ugly to add another check for a specific type of error, so maybe you have a better idea of what to do in this case? Not checking in the test case because 1) it's pretty specific (tried to change a few letters or something, test case doesn't fail anymore) and 2) it's happening only with --arm-asm-nop-fill, which isn't tested on tbpl as far as i know.

Comment on attachment 8714792 [details] [diff] [review] oom.patch Review of attachment 8714792 [details] [diff] [review]: ----------------------------------------------------------------- It looks OK, but it's a shame that |builder.abortReason() == AbortReason_Alloc| doesn't catch this. Maybe we can get away with only testing |cx->isThrowingOutOfMemory()|, or do you think it's possible to set the abort reason for this case?

For the record, IonBuilder::build returns false whether ion-building didn't work or we oom'd. There is an oom() function to set the abort reason and return false, but it's merely unused with respect to all the contexts that can oom, and that's a much bigger task to replace all of those. We agreed to push as is, at the moment.

Too late for assertion fixes in 46.