Quite a few tests tend to crash with the sampling profiler turned on, and after looking at them a bit, I came up with the following minimal test case that crashes about every second time on MIPS when run with jsc --useSamplingProfiler=true: function bar(a,b,c,d,e,f) { } noInline(bar); for (var i = 0; i < 10000; ++i) bar();
Created attachment 326449 [details] Output of jsc --useSamplingProfiler=1 --dumpDisassembly=true arity-test.js
Information I get from gdb: Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) info registers zero at v0 v1 a0 a1 a2 a3 R0 00000000 00000001 00000000 fffffffc 2f6f6000 2f780210 00000000 00000000 t0 t1 t2 t3 t4 t5 t6 t7 R8 000000ff 00000000 80028350 7fff6558 81010100 ffffffd0 6f662065 2f6fbcf8 s0 s1 s2 s3 s4 s5 s6 s7 R16 7fff65f8 7fff6a98 2f6f6000 2f7800a0 00d586c0 2f7b0110 2f6f6000 2f7e80d0 t8 t9 k0 k1 gp sp s8 ra R24 00000000 00660498 00000000 00000000 00d586c0 7fff64d0 00000000 00000000 status lo hi badvaddr cause pc 00001f13 000000c8 ffffff38 00000000 00800008 00000000 fcsr fir restart 08001004 00330000 00000000 (gdb) x/64a $sp 0x7fff64d0: 0x2f780210 0xfffffffc 0x2f7f6fc0 0xfffffffb 0x7fff64e0: 0x1 0x2d4e3e1c 0x2f7e80a0 0xfffffffb 0x7fff64f0: 0x0 0xfffffffc 0x0 0xfffffffc 0x7fff6500: 0x0 0xfffffffc 0x0 0xfffffffc 0x7fff6510: 0x0 0xfffffffc 0x0 0xfffffffc 0x7fff6520: 0x0 0xfffffffc 0x2f7f6fc0 0xfffffffb 0x7fff6530: 0x0 0xfffffffc 0x2f7d40a0 0xfffffffb 0x7fff6540: 0x2f7d40a0 0xfffffffb 0x7fff6590 0x722c10 <vmEntryToJavaScript+448> 0x7fff6550: 0x2f7800a0 0x0 0x2f7f6fa0 0xfffffffb 0x7fff6560: 0x1 0x2d4d67f4 0x2f7dc340 0xfffffffb 0x7fff6570: 0x0 0xfffffffc 0x2f7e80d0 0xa704e4 <JSC::ScriptExecutable::prepareForExecutionImpl(JSC::VM&, JSC::JSFunction*, JSC::JSScope*, JSC ::CodeSpecializationKind, JSC::CodeBlock*&)+380> 0x7fff6580: 0x2f6f6000 0x0 0x0 0x2d4b228c 0x7fff6590: 0x2f6f6000 0x6c4314 <JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*)+160> 0xd586c0 0xffffffff 0x7fff65a0: 0x0 0x2f7d40a0 0xd586c0 0x7fff6648 0x7fff65b0: 0x2d4e00b0 0x7fff65b8 0x7fff6a48 0x2d4b2288 0x7fff65c0: 0x7fff65f8 0x695550 <JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::ExecState*, JSC::JSObject*)+2508> 0x0 0x2f7b0 110 The addresses of jitted code are visible in the attached jsc-output.txt file.
Apologies, I should have started with that: the info I get from gdb with a debug version might be more useful: Program received signal SIGSEGV, Segmentation fault. 0x00e924e4 in WTF::RefCountedArray<JSC::Instruction>::begin (this=0x34) at ../../Source/WTF/wtf/RefCountedArray.h:141 141 T* begin() { return m_data; } (gdb) bt #0 0x00e924e4 in WTF::RefCountedArray<JSC::Instruction>::begin (this=0x34) at ../../Source/WTF/wtf/RefCountedArray.h:141 #1 0x013564f0 in JSC::CodeBlock::bytecodeOffset (this=0x0, returnAddress=0x2d4e6938) at ../../Source/JavaScriptCore/bytecode/CodeBlock.h:306 #2 0x0158a8e0 in JSC::slow_path_enter (warning: GDB can't find the start of the function at 0x2f500cb3. GDB is unable to find the start of the function at 0x2f500cb3 and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0x2f500cb3 for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. exec=0x7fff6248, pc=0x2d4e6938) at ../../Source/JavaScriptCore/runtime/CommonSlowPaths.cpp:680 #3 0x2f500cb4 in ?? () frame #3 is in the jitted code of bar(). I am going to attach the disassembly of it.
Created attachment 326456 [details] Disassembly of jit code for bar(), with the output of jsc (with --dumpDisassembly=true) at the beginning in comment for context. As we see here, it seems that frame #3 is in the [enter] part of bar(). I did try to put a jit breakpoint in emit_op_enter if the codeblock entry in the frame is 0 (which is what we see in the stack trace), and it is hit. Not sure yet where to go from there though, as I have a hard time figuring out where execution came into this. What looks like the storage of $ra in the stack points to garbage right after a c++ function. I wonder if we could be coming from OSR? In any case, I still don't understand the link with the Sampling Profiler.