[Webkit-unassigned] [Bug 182808] New: Crash: triggerOMGTierUpThunkGenerator() doesn't align the stack pointer before calling C++ code

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 14 14:41:00 PST 2018


            Bug ID: 182808
           Summary: Crash: triggerOMGTierUpThunkGenerator() doesn't align
                    the stack pointer before calling C++ code
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: msaboff at apple.com

When we try to tier up WASM code, we call the thunk generated by triggerOMGTierUpThunkGenerator().  The code genreated by that thunk doesn’t leave the stack pointer properly aligned before calling into C++ code.  That can lead to a crash, for example when xmm instructions are used on X86.

Here is such a crash caught in the debugger when navigating the site https://www.300mbfilms.co.

(lldb) bt
* thread #262, name = 'WebCore: Worker', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x000000010eaaab2a JavaScriptCore`WTF::WordLock::lockSlow() + 42
    frame #1: 0x000000010ea95a15 JavaScriptCore`WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) + 2277
    frame #2: 0x000000010ea8dcab JavaScriptCore`WTF::LockAlgorithm<unsigned char, (unsigned char)1, (unsigned char)2, WTF::EmptyLockHooks<unsigned char> >::lockSlow(WTF::Atomic<unsigned char>&) + 395
    frame #3: 0x000000010ea1ab31 JavaScriptCore`JSC::Wasm::Worklist::enqueue(WTF::Ref<JSC::Wasm::Plan, WTF::DumbPtrTraits<JSC::Wasm::Plan> >) + 209
    frame #4: 0x000000010ea0b26a JavaScriptCore`JSC::Wasm::OMGPlan::runForIndex(JSC::Wasm::Instance*, unsigned int) + 314
  * frame #5: 0x00002350f8f7b24b
    frame #6: 0x00002350f8eedc14
    frame #7: 0x00002350f8e4026c
    frame #8: 0x00002350f8e411e4
    frame #9: 0x000000010e06a1ba JavaScriptCore`vmEntryToJavaScript + 304
    frame #10: 0x000000010ea38e19 JavaScriptCore`JSC::callWebAssemblyFunction(JSC::ExecState*) + 3305
    frame #11: 0x000000010dede55c JavaScriptCore`JSC::LLInt::setUpCall(JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 812
    frame #12: 0x000000010e717905 JavaScriptCore`JSC::LLInt::varargsSetup(JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::LLInt::SetArgumentsWith) + 373
    frame #13: 0x000000010e07196e JavaScriptCore`llint_entry + 30156
    frame #14: 0x000000010e07151c JavaScriptCore`llint_entry + 29050
    frame #15: 0x000000010e07151c JavaScriptCore`llint_entry + 29050
    frame #16: 0x000000010e07151c JavaScriptCore`llint_entry + 29050
    frame #17: 0x000000010e06a1ba JavaScriptCore`vmEntryToJavaScript + 304
    frame #18: 0x000000010e6c81d3 JavaScriptCore`JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 147
    frame #19: 0x000000010dee0fb4 JavaScriptCore`JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 548
    frame #20: 0x000000010dee0d7e JavaScriptCore`JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 62
    frame #21: 0x000000010e89d8a2 JavaScriptCore`JSC::boundThisNoArgsFunctionCall(JSC::ExecState*) + 498
    frame #22: 0x000000010e06a334 JavaScriptCore`vmEntryToNative + 310
    frame #23: 0x000000010dee0ff2 JavaScriptCore`JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 610
    frame #24: 0x000000010e81aad5 JavaScriptCore`JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&) + 165
    frame #25: 0x000000010bcf967c WebCore`WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext&, WebCore::Event&) + 1324
    frame #26: 0x000000010bf24aa1 WebCore`WebCore::EventTarget::fireEventListeners(WebCore::Event&, WTF::Vector<WTF::RefPtr<WebCore::RegisteredEventListener, WTF::DumbPtrTraits<WebCore::RegisteredEventListener> >, 1ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>) + 801
    frame #27: 0x000000010bf2173d WebCore`WebCore::EventTarget::fireEventListeners(WebCore::Event&) + 525
    frame #28: 0x000000010bf24764 WebCore`WebCore::EventTarget::dispatchEvent(WebCore::Event&) + 100
    frame #29: 0x000000010c6ba5ca WebCore`WTF::Function<void (WebCore::ScriptExecutionContext&)>::CallableWrapper<WebCore::WorkerMessagingProxy::postMessageToWorkerGlobalScope(WebCore::MessageWithMessagePorts&&)::$_1>::call(WebCore::ScriptExecutionContext&) + 122
    frame #30: 0x000000010c6b7a40 WebCore`WebCore::WorkerRunLoop::runInMode(WebCore::WorkerGlobalScope*, WebCore::ModePredicate const&, WebCore::WorkerRunLoop::WaitMode) + 416
    frame #31: 0x000000010c6b7840 WebCore`WebCore::WorkerRunLoop::run(WebCore::WorkerGlobalScope*) + 96
    frame #32: 0x000000010c6b9e09 WebCore`WebCore::WorkerThread::workerThread() + 1033
    frame #33: 0x000000010eaa6c74 JavaScriptCore`WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) + 228
    frame #34: 0x000000010dea8bd9 JavaScriptCore`WTF::wtfThreadEntryPoint(void*) + 9
    frame #35: 0x00007fff52d2a6c1 libsystem_pthread.dylib`_pthread_body + 340
    frame #36: 0x00007fff52d2a56d libsystem_pthread.dylib`_pthread_start + 377
    frame #37: 0x00007fff52d29c5d libsystem_pthread.dylib`thread_start + 13

Here are the registers at the time of the call to OMGPlan::runForIndex():
(lldb) reg read
General Purpose Registers:
       rbx = 0xc40e7e81eb2949ab
       rbp = 0x00007000056cff00
       rsp = 0x00007000056cfb78
       r12 = 0x4690e8c824170384
       r13 = 0x0000001301a00000
       r14 = 0x26da7ff9c0942383
       r15 = 0x700904baa04ca7f4
       rip = 0x00002350f8f7b24b

Here is the disassembly og the stub:
(lldb) di -s 0x2350f8f7b180 -c 60
    0x2350f8f7b180: subq   $0xd0, %rsp
    0x2350f8f7b187: movq   %rax, (%rsp)
    0x2350f8f7b18b: movq   %rcx, 0x8(%rsp)
    0x2350f8f7b190: movq   %rdx, 0x10(%rsp)
    0x2350f8f7b195: movq   %rsi, 0x18(%rsp)
    0x2350f8f7b19a: movq   %rdi, 0x20(%rsp)
    0x2350f8f7b19f: movq   %r8, 0x28(%rsp)
    0x2350f8f7b1a4: movq   %r9, 0x30(%rsp)
    0x2350f8f7b1a9: movq   %r10, 0x38(%rsp)
    0x2350f8f7b1ae: movq   %r11, 0x40(%rsp)
    0x2350f8f7b1b3: movsd  %xmm0, 0x48(%rsp)
    0x2350f8f7b1b9: movsd  %xmm1, 0x50(%rsp)
    0x2350f8f7b1bf: movsd  %xmm2, 0x58(%rsp)
    0x2350f8f7b1c5: movsd  %xmm3, 0x60(%rsp)
    0x2350f8f7b1cb: movsd  %xmm4, 0x68(%rsp)
    0x2350f8f7b1d1: movsd  %xmm5, 0x70(%rsp)
    0x2350f8f7b1d7: movsd  %xmm6, 0x78(%rsp)
    0x2350f8f7b1dd: movsd  %xmm7, 0x80(%rsp)
    0x2350f8f7b1e6: movsd  %xmm8, 0x88(%rsp)
    0x2350f8f7b1f0: movsd  %xmm9, 0x90(%rsp)
    0x2350f8f7b1fa: movsd  %xmm10, 0x98(%rsp)
    0x2350f8f7b204: movsd  %xmm11, 0xa0(%rsp)
    0x2350f8f7b20e: movsd  %xmm12, 0xa8(%rsp)
    0x2350f8f7b218: movsd  %xmm13, 0xb0(%rsp)
    0x2350f8f7b222: movsd  %xmm14, 0xb8(%rsp)
    0x2350f8f7b22c: movsd  %xmm15, 0xc0(%rsp)
    0x2350f8f7b236: movq   %gs:0x2e8, %rdi
    0x2350f8f7b23f: movabsq $0x10ea0b130, %rdx        ; imm = 0x10EA0B130 
    0x2350f8f7b249: callq  *%rdx
    0x2350f8f7b24b: movq   (%rsp), %rax
    0x2350f8f7b24f: movq   0x8(%rsp), %rcx
    0x2350f8f7b254: movq   0x10(%rsp), %rdx
    0x2350f8f7b259: movq   0x18(%rsp), %rsi
    0x2350f8f7b25e: movq   0x20(%rsp), %rdi
    0x2350f8f7b263: movq   0x28(%rsp), %r8
    0x2350f8f7b268: movq   0x30(%rsp), %r9
    0x2350f8f7b26d: movq   0x38(%rsp), %r10
    0x2350f8f7b272: movq   0x40(%rsp), %r11
    0x2350f8f7b277: movsd  0x48(%rsp), %xmm0         ; xmm0 = mem[0],zero 
    0x2350f8f7b27d: movsd  0x50(%rsp), %xmm1         ; xmm1 = mem[0],zero 
    0x2350f8f7b283: movsd  0x58(%rsp), %xmm2         ; xmm2 = mem[0],zero 
    0x2350f8f7b289: movsd  0x60(%rsp), %xmm3         ; xmm3 = mem[0],zero 
    0x2350f8f7b28f: movsd  0x68(%rsp), %xmm4         ; xmm4 = mem[0],zero 
    0x2350f8f7b295: movsd  0x70(%rsp), %xmm5         ; xmm5 = mem[0],zero 
    0x2350f8f7b29b: movsd  0x78(%rsp), %xmm6         ; xmm6 = mem[0],zero 
    0x2350f8f7b2a1: movsd  0x80(%rsp), %xmm7         ; xmm7 = mem[0],zero 
    0x2350f8f7b2aa: movsd  0x88(%rsp), %xmm8         ; xmm8 = mem[0],zero 
    0x2350f8f7b2b4: movsd  0x90(%rsp), %xmm9         ; xmm9 = mem[0],zero 
    0x2350f8f7b2be: movsd  0x98(%rsp), %xmm10        ; xmm10 = mem[0],zero 
    0x2350f8f7b2c8: movsd  0xa0(%rsp), %xmm11        ; xmm11 = mem[0],zero 
    0x2350f8f7b2d2: movsd  0xa8(%rsp), %xmm12        ; xmm12 = mem[0],zero 
    0x2350f8f7b2dc: movsd  0xb0(%rsp), %xmm13        ; xmm13 = mem[0],zero 
    0x2350f8f7b2e6: movsd  0xb8(%rsp), %xmm14        ; xmm14 = mem[0],zero 
    0x2350f8f7b2f0: movsd  0xc0(%rsp), %xmm15        ; xmm15 = mem[0],zero 
    0x2350f8f7b2fa: addq   $0xd0, %rsp
    0x2350f8f7b301: retq 

The stack space needed to save registers is aligned.  The problem is that the stub doesn’t have a properly prologue that will align the stack pointer before the subtraction of the space needed to save registers.

Adding a proper prologue and epilogue should fix the problem.

This crash happens in current ToT (r228472) and exists in Elkmet as well.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180214/b3d8add1/attachment.html>

More information about the webkit-unassigned mailing list