[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
https://bugs.webkit.org/show_bug.cgi?id=182808
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