Bug 179479 – [JSC][MIPS] Sampling Profiler crashes with functions of arity >=6

• Component: JavaScriptCore
• Status: NEW

[Guillaume Emont]

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();

[Guillaume Emont]

Created attachment 326449 [details]
Output of jsc --useSamplingProfiler=1 --dumpDisassembly=true arity-test.js

[Guillaume Emont]

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.

[Guillaume Emont]

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.

[Guillaume Emont]

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.