The following testcase crashes on mozilla-central revision 4a3275936ddf (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize --enable-simulator=arm64, run with --fuzzing-safe --baseline-eager): enableGeckoProfiling("Math.round", "-0.49", -0); function* g(n) { for (var i = 0; i < n; i++) yield i; } var inner = g(20); for (let target of inner) { if (GeneratorObjectPrototype() == i(true, true) == (this) == (this)) {} } Backtrace: received signal SIGINT, Interrupt. 0x00007ffff7bcb269 in raise (sig=sig@entry=2) at ../sysdeps/unix/sysv/linux/pt-raise.c:35 #0 0x00007ffff7bcb269 in raise (sig=sig@entry=2) at ../sysdeps/unix/sysv/linux/pt-raise.c:35 #1 0x00000000009ee20a in vixl::HostBreakpoint (code=0) at js/src/jit/arm64/vixl/Platform-vixl.h:36 #2 vixl::Simulator::VisitException (this=<optimized out>, instr=<optimized out>) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:471 #3 0x0000000000980560 in vixl::Decoder::VisitException (this=<optimized out>, instr=0x3ce3b881ee9c) at js/src/jit/arm64/vixl/Decoder-vixl.cpp:872 #4 0x00000000009df7e5 in vixl::Decoder::Decode (instr=<optimized out>, this=<optimized out>) at js/src/jit/arm64/vixl/Decoder-vixl.h:158 #5 vixl::Simulator::ExecuteInstruction (this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:195 #6 0x00000000009e1e3c in vixl::Simulator::Run (this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:70 #7 0x00000000009dfcd0 in vixl::Simulator::RunFrom (first=0x7ffff4c1fc40, this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:78 #8 vixl::Simulator::call (this=0x7ffff5f3b000, entry=entry@entry=0x3ce3b8807960 "\376w\277\251\375\003", argument_count=argument_count@entry=8) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:327 #9 0x0000000000786a65 in EnterJit (cx=<optimized out>, cx@entry=0x7ffff5f15000, state=..., code=0x3ce3b88077d0 "\237#") at js/src/jit/Jit.cpp:101 #10 0x00000000007872dc in js::jit::MaybeEnterJit (cx=cx@entry=0x7ffff5f15000, state=...) at js/src/jit/Jit.cpp:163 #11 0x000000000056bf81 in js::RunScript (cx=0x7ffff5f15000, state=...) at js/src/vm/Interpreter.cpp:402 #12 0x000000000056c737 in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0x7ffff5f15000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:489 #13 0x000000000056ca4d in InternalCall (cx=0x7ffff5f15000, args=...) at js/src/vm/Interpreter.cpp:516 #14 0x000000000056cb9a in js::CallFromStack (cx=<optimized out>, args=...) at js/src/vm/Interpreter.cpp:522 #15 0x000000000063d3b3 in js::jit::DoCallFallback (cx=<optimized out>, frame=0x7ffff4c1fea8, stub_=<optimized out>, argc=<optimized out>, vp=0x7ffff4c1fe28, res=...) at js/src/jit/BaselineIC.cpp:2380 #16 0x00000000009e923e in vixl::Simulator::VisitCallRedirection (this=0x7ffff5f3b000, instr=0x7ffff5f87208) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:646 #17 0x00000000009ee3c5 in vixl::Simulator::VisitException (this=0x7ffff5f3b000, instr=<optimized out>) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:479 #18 0x0000000000980560 in vixl::Decoder::VisitException (this=<optimized out>, instr=0x7ffff5f87208) at js/src/jit/arm64/vixl/Decoder-vixl.cpp:872 #19 0x00000000009df7e5 in vixl::Decoder::Decode (instr=<optimized out>, this=<optimized out>) at js/src/jit/arm64/vixl/Decoder-vixl.h:158 #20 vixl::Simulator::ExecuteInstruction (this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:195 #21 0x00000000009e1e3c in vixl::Simulator::Run (this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:70 #22 0x00000000009dfcd0 in vixl::Simulator::RunFrom (first=0x7fffffffc600, this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:78 #23 vixl::Simulator::call (this=0x7ffff5f3b000, entry=entry@entry=0x3ce3b8807960 "\376w\277\251\375\003", argument_count=argument_count@entry=8) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:327 #24 0x0000000000786a65 in EnterJit (cx=<optimized out>, cx@entry=0x7ffff5f15000, state=..., code=0x3ce3b88284f0 "\237#") at js/src/jit/Jit.cpp:101 [...] #35 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:9137 rax 0x0 0 rbx 0x7ffff5f59060 140737319899232 rcx 0x7ffff7bcb269 140737349726825 rdx 0x2 2 rsi 0x3c66 15462 rdi 0x3c66 15462 rbp 0x7fffffffb930 140737488337200 rsp 0x7fffffffb8d8 140737488337112 r8 0x130e8e8 19982568 r9 0x0 0 r10 0xa5 165 r11 0x206 518 r12 0x7ffff5f59068 140737319899240 r13 0x980400 9962496 r14 0x7ffff5f3b000 140737319776256 r15 0x3ce3b881ee9c 66948750765724 rip 0x7ffff7bcb269 <raise+41> => 0x7ffff7bcb269 <raise+41>: cmp $0xfffffffffffff000,%rax 0x7ffff7bcb26f <raise+47>: ja 0x7ffff7bcb278 <raise+56> This was found on real hardware, but turned out to reproduce in the simulator as well.

Hmm. ARM64. Sean?

P2 because this was a reproducible crash and sstangl is now working on Ion for ARM64.

I would say that this is a [fuzzblocker] for ARM64 testing due to its frequency.

Taking this bug as this is a fuzzblocker.

The problem seems to be we set the lastProfilingFrame under BaselineCodeGen<BaselineCompilerHandler>::emit_JSOP_RESUME(), and never undo it, before reaching the code produced by generateProfilerExitFrameTailStub presumably from the parent frame. As we never undo the changes made to the lastProfilingFrame field of the JitActivation, it does not match the stack pointer of the parent frame, and as such reach into the assumeReachable code path of the generated code, and fails.

Comparing with x64 execution, it seems to be that the stack pointer seen at the time of the execution of the generateProfilerExitFrameTailStub's code is wrong not the one set previously while running the JSOP_RESUME instruction. The profiler exit frame tail stub is called by the HandleException mechanism after the call to GeneratorThrowOrReturn which is a bit later in the code of JSOP_RESUME code emitted for Baseline. So the problem might likely coming from from the logic for JS_USE_LINK_REGISTER and potentially the extra JS_CODEGEN_ARM64 before the jump in the GeneratorThrowOrReturn VM wrapper.

The problem is that the ARM64 variant of handleFailureWithHandlerTail is lacking the code [1] needed to reset the profiling information to the previous frame. As opposed to what the comment mention above the given code section, this is not only a Debug-only case, but this is also be used for the ResumeKind::Return case of JSOP_RESUME. [1] https://searchfox.org/mozilla-central/rev/fe3fa7f53037d4e869858fef4ff9310dfa795c41/js/src/jit/x64/MacroAssembler-x64.cpp#212-220

Comment on attachment 9033428 [details] [diff] [review] ARM64: Update the last profiling frame after a JSOP_RESUME return opcode. Review of attachment 9033428 [details] [diff] [review]: ----------------------------------------------------------------- Great find! Thank you for tracking it down. I suppose that code was added in the last few years since that function was written, but the ARM64 port was forgotten about.

Pushed by npierron@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/86afdee4cff9 ARM64: Update the last profiling frame after a JSOP_RESUME return opcode. r=sstangl