The following testcase crashes on mozilla-central revision 29d5a4175c8b (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-debug, run with --fuzzing-safe --ion-offthread-compile=off): function cold_and_warm(f, params) entryPoints(params) function entry1() { }; buf = "cold_and_warm(entry1, { function: entry1 });"; loadFile(buf); loadFile(buf); function loadFile(lfVarx) { oomTest(function() eval(lfVarx)) } Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0818f03d in js::CheckForInterrupt (cx=0xf7a79020) at js/src/jscntxt.h:667 #0 0x0818f03d in js::CheckForInterrupt (cx=0xf7a79020) at js/src/jscntxt.h:667 #1 0x0870ab86 in Interpret (cx=cx@entry=0xf7a79020, state=...) at js/src/vm/Interpreter.cpp:1897 #2 0x0871a51f in js::RunScript (cx=cx@entry=0xf7a79020, state=...) at js/src/vm/Interpreter.cpp:426 #3 0x0871a7fa in js::Invoke (cx=0xf7a79020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:494 #4 0x0871bf4a in js::Invoke (cx=cx@entry=0xf7a79020, thisv=..., fval=..., argc=0, argv=0x0, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:528 #5 0x08556024 in JS::Call (cx=0xf7a79020, thisv=..., fval=fval@entry=..., args=..., rval=rval@entry=...) at js/src/jsapi.cpp:2899 #6 0x080f7343 in EntryPoints (cx=0xf7a79020, argc=1, vp=0xf4227178) at js/src/shell/js.cpp:5040 #7 0x0871e30a in js::CallJSNative (cx=0xf7a79020, native=0x80f7180 <EntryPoints(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235 #8 0x0871a79d in js::Invoke (cx=0xf7a79020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:476 #9 0x0870a38a in Interpret (cx=cx@entry=0xf7a79020, state=...) at js/src/vm/Interpreter.cpp:2807 #10 0x0871a51f in js::RunScript (cx=cx@entry=0xf7a79020, state=...) at js/src/vm/Interpreter.cpp:426 #11 0x0871d30d in js::ExecuteKernel (cx=cx@entry=0xf7a79020, script=..., script@entry=..., scopeChainArg=..., newTargetValue=..., evalInFrame=evalInFrame@entry=..., result=0xffffba88) at js/src/vm/Interpreter.cpp:682 #12 0x084c5d2b in EvalKernel (cx=cx@entry=0xf7a79020, args=..., evalType=evalType@entry=DIRECT_EVAL, caller=..., scopeobj=..., scopeobj@entry=..., pc=0xf43526c9 "{") at js/src/builtin/Eval.cpp:332 #13 0x084c6732 in js::DirectEval (cx=cx@entry=0xf7a79020, args=...) at js/src/builtin/Eval.cpp:439 #14 0x08280335 in js::jit::DoCallFallback (cx=0xf7a79020, frame=0xffffbac8, stub_=0xf7aa80b0, argc=1, vp=0xffffba88, res=...) at js/src/jit/BaselineIC.cpp:6100 #15 0xf7fcedce in ?? () #16 0xf7aa80b0 in ?? () #17 0xf7fc8c5c in ?? () #18 0x0825cd1a in EnterBaseline (cx=0xf7aa80b0, cx@entry=0xf7a79020, data=...) at js/src/jit/BaselineJIT.cpp:150 #19 0x0827ab9e in js::jit::EnterBaselineMethod (cx=cx@entry=0xf7a79020, state=...) at js/src/jit/BaselineJIT.cpp:188 #20 0x0871a5bb in js::RunScript (cx=cx@entry=0xf7a79020, state=...) at js/src/vm/Interpreter.cpp:416 #21 0x0871a7fa in js::Invoke (cx=0xf7a79020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:494 #22 0x0871bf4a in js::Invoke (cx=cx@entry=0xf7a79020, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0x0, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:528 #23 0x08556d30 in JS_CallFunction (cx=cx@entry=0xf7a79020, obj=..., fun=fun@entry=..., args=..., rval=rval@entry=...) at js/src/jsapi.cpp:2865 #24 0x0886737b in OOMTest (cx=0xf7a79020, argc=1, vp=0xf42270b0) at js/src/builtin/TestingFunctions.cpp:1311 [...] #37 main (argc=4, argv=0xffffccd4, envp=0xffffcce8) at js/src/shell/js.cpp:7443 eax 0x0 0 ebx 0x98a9314 160076564 ecx 0xf7e3a88c -136075124 edx 0x0 0 esi 0xf4227190 -199069296 edi 0xf4558b80 -195720320 ebp 0xffffa738 4294944568 esp 0xffffa720 4294944544 eip 0x818f03d <js::CheckForInterrupt(JSContext*)+77> => 0x818f03d <js::CheckForInterrupt(JSContext*)+77>: movl $0x29b,0x0 0x818f047 <js::CheckForInterrupt(JSContext*)+87>: call 0x8107f70 <abort()>

JSBugMon: Bisection requested, result: === Treeherder Build Bisection Results by autoBisect === The "good" changeset has the timestamp "20160302090939" and the hash "09bb9469a14d4587e44027e648438a5f23526cd7". The "bad" changeset has the timestamp "20160302093919" and the hash "9de2c10a1cc34fdeade8523b53f03d567e7f190b". Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=09bb9469a14d4587e44027e648438a5f23526cd7&tochange=9de2c10a1cc34fdeade8523b53f03d567e7f190b

Might be related to bug 1252905, the only one in JS in the regression window.

> Might be related to bug 1252905, the only one in JS in the regression window. Well, that patch added the assertion that's failing, so...

OK, so now the bad news. On my Linux system, compiling the given revision with the configure options from comment 0 fails: /home/bzbarsky/mozilla/vanilla/mozilla/js/src/jit/x86/MacroAssembler-x86-inl.h:400:18: error: ‘struct js::jit::Register64’ has no member named ‘low’ movl(lhs.low, temp); ^ /home/bzbarsky/mozilla/vanilla/mozilla/js/src/jit/x86/MacroAssembler-x86-inl.h:401:17: error: ‘struct js::jit::Register64’ has no member named ‘high’ orl(lhs.high, temp); etc. Presumably something is broken about trying to compile a 32-bit SpiderMonkey that way on a 64-bit system. Are you compiling on a 32-bit system? Compiling without --target=i686-pc-linux-gnu succeeds but does not reproduce the bug with the runtime options from comment 0.

Anyway, the relevant CHECK_BRANCH() is in the JSOP_RETRVAL case. That case has this comment: /* * When the inlined frame exits with an exception or an error, ok will be * false after the inline_return label. */ (there is no "ok" anywhere around; the closest is interpReturnOK. Seems like we should condition this CHECK_BRANCH on there being no pending exception or something. Possibly move it down to where we have set interpReturnOK, though that would change the semantics. Or we could JS_HasPendingException(cx) or equivalent. Jan, thoughts?

OOM bug in ShellAutoEntryMonitor::Entry. That function can't easily report OOM because it's called from a constructor, so this patch recovers - we report OOM in buildResult.

(In reply to Boris Zbarsky [:bz] from comment #5) > Jan, thoughts? I think the interpreter is fine and we shouldn't be executing JSOP_RETRVAL if there's a pending exception. Unfortunately every time we add a cx->isExceptionPending() assert, it helps the fuzzers find more of these bugs. The more of those asserts we have, the better. We're making great progress fixing these OOM bugs though. As for the build error, do you need to set AR=ar CC="gcc -m32" CXX="g++ -m32" ?

Clearing needinfo because I think jandem already posted the solution here. If building with the CC/CXX variables that jandem mentioned doesn't work, please let me know.

Yeah, compiling with those env vars works.