SIGSEGV in JSC::revertCall in 250230.2.1

[danmaas]

Hi @Kudo - Thank you so much for creating this improved version of the jsc-android package. Really appreciate your effort in solving some of the upstream bugs.

My React Native app uses your 250230.2.1 release and I am seeing a trend of crashes affecting ~1% of user sessions. The issue is a SIGSEGV in libjsc.so's JSC::revertCall() (full backtraces below).

I combed through recent WebKit changelogs affecting the file that contains that function (jit/Repatch.cpp). Two stuck out to me as possibly relevant to these crashes; one fixes a use-after-free issue and the other fixes a failure to lock one of the data structures involved:
https://trac.webkit.org/changeset/253361/webkit
https://trac.webkit.org/changeset/264388/webkit

How much work is it to bump up to a newer version of WebKit? Is this something I can help with?

Sample backtraces (click to expand)

Backtrace 1:

JSC::revertCall(JSC::VM&, JSC::CallLinkInfo&, JSC::MacroAssemblerCodeRef<(WTF::PtrTag)49594>)
JSC::unlinkFor(JSC::VM&, JSC::CallLinkInfo&)
JSC::CallLinkInfo::unlink(JSC::VM&)
JSC::PolymorphicCallNode::unlink(JSC::VM&)
JSC::CodeBlock::unlinkIncomingCalls()
JSC::ScriptExecutable::installCode(JSC::VM&, JSC::CodeBlock*, JSC::CodeType, JSC::CodeSpecializationKind)
JSC::JITWorklist::Plan::finalize()∫
JSC::JITWorklist::poll(JSC::VM&)
JSC::LLInt::jitCompileAndSetHeuristics(JSC::CodeBlock*, JSC::ExecState*, unsigned int)
JSC::LLInt::entryOSR(JSC::ExecState*, JSC::Instruction const*, JSC::CodeBlock*, char const*, JSC::LLInt::EntryKind)
llint_op_enter_wide32

Backtrace 2:

JSC::revertCall(JSC::VM&, JSC::CallLinkInfo&, JSC::MacroAssemblerCodeRef<(WTF::PtrTag)49594>)
JSC::unlinkFor(JSC::VM&, JSC::CallLinkInfo&)
JSC::CallLinkInfo::unlink(JSC::VM&)
JSC::PolymorphicCallNode::unlink(JSC::VM&)
JSC::CodeBlock::unlinkIncomingCalls()
JSC::ScriptExecutable::installCode(JSC::VM&, JSC::CodeBlock*, JSC::CodeType, JSC::CodeSpecializationKind)
JSC::CodeBlock::jettison(JSC::Profiler::JettisonReason, JSC::ReoptimizationMode, JSC::FireDetail const*)
JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally(JSC::VM&)
void JSC::IsoCellSet::forEachMarkedCell<void JSC::Heap::finalizeMarkedUnconditionalFinalizers<JSC::ExecutableToCodeBlockEdge, JSC::IsoCellSet>(JSC::IsoCellSet&)::{lambda(JSC::HeapCell*, JSC::HeapCell::Kind)#1}>(void JSC::Heap::finalizeMarkedUnconditionalFinalizers<JSC::ExecutableToCodeBlockEdge, JSC::IsoCellSet>(JSC::IsoCellSet&)::{lambda(JSC::HeapCell*, JSC::HeapCell::Kind)#1} const&)
JSC::Heap::finalizeUnconditionalFinalizers()
JSC::Heap::runEndPhase(JSC::GCConductor)
JSC::Heap::runCurrentPhase(JSC::GCConductor, JSC::CurrentThreadState*)
JSC::Heap::HeapThread::work()
WTF::Detail::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0, void>::call()
WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)
WTF::wtfThreadEntryPoint(void*)
JSC::BuiltinExecutables::functionPrototypeBindCodeExecutable()

Linking react-native-community#132 for reference; the backtraces are different but that thread seems to be tracking various native crashes due to upstream WebKit faults.

[Kudo]

Hi @danmaas, thanks for your brief information. I've tried to upgrade to WebkitGTK 2.28.3 last week.
The build so far is passed.
Unfortunately, there was a crash on Android emulator armeabi-v7a API 16 for SIGILL - ILL_ILLOPC.
The crash seems not happened on real device (also armeabi-v7a API 16).
I still need to take some time to clarify the problem of ILL_ILLOPC.

The work so far is at webkitgtk_2_28_3 branch.

[danmaas]

Great to hear the update! I will look at the new branch soon.

I have seen a few SIGILL crashes in production on real devices (with 250230.2.1). But I am not sure if these crashes are related to libjsc or not (example: https://sentry.io/share/issue/8b3a6ca132cd46059610fd6a4bfc4009/). The number of SIGILL crashes is much lower than the JSC::revertCall crash.

[danmaas]

Just an update - I've switched my app to Hermes and that has fixed the high crash rates.