Bug 177901 – REGRESSION: LayoutTest workers/wasm-hashset.html is a flaky crash

• Component: JavaScriptCore
• Status: RESOLVED DUPLICATE

[Ryan Haddad]

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

[Ryan Haddad]

The other crashes I see when looking at results on the flakiness dashboard have different backtraces.

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=workers%2Fwasm-hashset.html

https://build.webkit.org/results/Apple%20Sierra%20Debug%20WK2%20(Tests)/r222795%20(3328)/workers/wasm-hashset-crash-log.txt

https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK1%20(Tests)/r222842%20(4010)/workers/wasm-hashset-crash-log.txt

[Ryan Haddad]

I think this may have started with https://trac.webkit.org/changeset/222791/webkit

[JF Bastien]

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]

It could also be something about tiering, I haven't tried disabling it yet, will try on asan build.

[Ryan Haddad]

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 ***