RESOLVED DUPLICATE of bug 177473 177901
REGRESSION: LayoutTest workers/wasm-hashset.html is a flaky crash
https://bugs.webkit.org/show_bug.cgi?id=177901
Summary REGRESSION: LayoutTest workers/wasm-hashset.html is a flaky crash
Ryan Haddad
Reported 2017-10-04 15:42:03 PDT
LayoutTest workers/wasm-hashset.html is a flaky crash SHOULD NEVER BE REACHED ./interpreter/CallFrame.cpp(77) : bool JSC::ExecState::callSiteBitsAreCodeOriginIndex() const 1 0x11e5c7980 WTFCrash 2 0x11e2c6b92 JSC::ExecState::callSiteBitsAreCodeOriginIndex() const 3 0x11e2c6e6a JSC::ExecState::bytecodeOffset() 4 0x11e2d05e6 JSC::StackVisitor::readNonInlinedFrame(JSC::ExecState*, JSC::CodeOrigin*) 5 0x11e2cffe3 JSC::StackVisitor::readFrame(JSC::ExecState*) 6 0x11e2d01d3 JSC::StackVisitor::gotoNextFrame() 7 0x11e2cb1f3 void JSC::StackVisitor::visit<JSC::Interpreter::getStackTrace(JSC::JSCell*, WTF::Vector<JSC::StackFrame, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, unsigned long, unsigned long)::$_3>(JSC::ExecState*, JSC::VM*, JSC::Interpreter::getStackTrace(JSC::JSCell*, WTF::Vector<JSC::StackFrame, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, unsigned long, unsigned long)::$_3 const&) 8 0x11e2cb022 JSC::Interpreter::getStackTrace(JSC::JSCell*, WTF::Vector<JSC::StackFrame, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, unsigned long, unsigned long) 9 0x11e5b212f JSC::Exception::finishCreation(JSC::VM&, JSC::JSValue, JSC::Exception::StackCaptureAction) 10 0x11e5b2045 JSC::Exception::create(JSC::VM&, JSC::JSValue, JSC::Exception::StackCaptureAction) 11 0x11d605c8e JSC::VM::throwException(JSC::ExecState*, JSC::JSValue) 12 0x11d5e01c5 JSC::ThrowScope::throwException(JSC::ExecState*, JSC::JSValue) 13 0x11d222cad JSC::throwException(JSC::ExecState*, JSC::ThrowScope&, JSC::JSValue) 14 0x11e39f645 llint_slow_path_throw 15 0x11d206c70 llint_entry 16 0x11d2061c1 llint_entry 17 0x11d2061c1 llint_entry 18 0x11d2061c1 llint_entry 19 0x11d1fe587 vmEntryToJavaScript 20 0x11e32dee1 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) 21 0x11e2cd445 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 22 0x11e536390 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 23 0x11e536469 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&) 24 0x11e5366cd JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&) 25 0x110fda27b WebCore::JSMainThreadExecState::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&) 26 0x112512564 WebCore::ScheduledAction::executeFunctionInContext(JSC::JSGlobalObject*, JSC::JSValue, WebCore::ScriptExecutionContext&) 27 0x112512148 WebCore::ScheduledAction::execute(WebCore::Document&) 28 0x112512003 WebCore::ScheduledAction::execute(WebCore::ScriptExecutionContext&) 29 0x11065434f WebCore::DOMTimer::fired() 30 0x112a64722 WebCore::ThreadTimers::sharedTimerFiredInternal() 31 0x112a64da1 WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::$_0::operator()() const https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK2%20(Tests)/r222860%20(3432)/results.html
Attachments
Ryan Haddad
Comment 2 2017-10-04 15:59:01 PDT
I think this may have started with https://trac.webkit.org/changeset/222791/webkit
JF Bastien
Comment 3 2017-10-05 14:48:16 PDT
Yeah it's likely related to my change. I repro-d locally, definitely flaky and generates different backtraces each time. I'm guessing it's a memory corruption, and since this is a worker test which instantiates the same wasm module multiple times. The bug doesn't occur in the jsc shell wasm tests, so the bug isn't likely to be some other memory corruption. It's likely that Wasm::Module isn't refcounted properly. That's odd though, I use ThreadSafeRefCounted which should be fine. It could also be CodeBlock or some other thing. I'll try out an asan build and see if that finds anything.
JF Bastien
Comment 4 2017-10-05 14:51:04 PDT
It could also be something about tiering, I haven't tried disabling it yet, will try on asan build.
Ryan Haddad
Comment 5 2017-10-06 15:14:16 PDT
Rolled this change out in https://trac.webkit.org/r223002. Duping this to the original bug. *** This bug has been marked as a duplicate of bug 177473 ***
Note You need to log in before you can comment on or make changes to this bug.