<html>
    <head>
      <base href="https://bugs.webkit.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [Android] 64-bit JSC r245459 crashes in JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&)"
   href="https://bugs.webkit.org/show_bug.cgi?id=200983">200983</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>[Android] 64-bit JSC r245459 crashes in JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&)
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>WebKit
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>WebKit Nightly Build
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>Other
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>Blocker
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P2
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>JavaScriptCore
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>webkit-unassigned@lists.webkit.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>prti@amazon.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Hi folks, 
As part of google’s Support 64-bit architectures (<a href="https://developer.android.com/distribute/best-practices/develop/64-bit">https://developer.android.com/distribute/best-practices/develop/64-bit</a>) requirement, Amazon Alexa (<a href="https://play.google.com/store/apps/details?id=com.amazon.dee.app&hl=en_US">https://play.google.com/store/apps/details?id=com.amazon.dee.app&hl=en_US</a>) launched 64-bit version of Android app on July-30, 2019 based on an O3-optimized JSC (<a href="https://trac.webkit.org/r245459">r245459</a>). 
While stability is vastly improved compared to our earlier attempts, there are still residual problems. We see a crash rate of 0.35% over cold starts from the 64-bit JSC seg faults alone. 
Following is the stack-trace and currently the reproduction steps are unknown to us as we are unable to reproduce this crash in our in-house testing.

SIGSEGV
MainActivity
Segmentation violation (invalid memory reference)
Aug 14th, 2019, 11:32:55 UTC

STACKTRACE

SIGSEGV: Segmentation violation (invalid memory reference)
        JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const at sfp-exceptions.c:?
        JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const at sfp-exceptions.c:?
        JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&) at sfp-exceptions.c:?
        JSC::ExecutableToCodeBlockEdge::runConstraint(JSC::ConcurrentJSLocker const&, JSC::VM&, JSC::SlotVisitor&) at sfp-exceptions.c:?
        JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&) at sfp-exceptions.c:?
        JSC::SlotVisitor::drain(WTF::MonotonicTime)::$_3::operator()(JSC::MarkStackArray&) const at sfp-exceptions.c:?
        JSC::SlotVisitor::drain(WTF::MonotonicTime) at sfp-exceptions.c:?
        JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime) at sfp-exceptions.c:?
        WTF::SharedTaskFunctor<void (), JSC::Heap::runBeginPhase(JSC::GCConductor)::$_17>::run() at sfp-exceptions.c:?
        WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::SharedTask<void ()> > > const&) at sfp-exceptions.c:?
        WTF::ParallelHelperPool::Thread::work() at sfp-exceptions.c:?
        WTF::Function<void ()>::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0>::call() at sfp-exceptions.c:?
        WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) at sfp-exceptions.c:?
        WTF::wtfThreadEntryPoint(void*) at sfp-exceptions.c:?
        at 0x7f89700484(/system/lib64/libc.so:427140)
        at 0x7f896b5db4(/system/lib64/libc.so:122292)
        at 0x0(Unknown)

The React Native community reports the same issue in <a href="https://github.com/facebook/react-native/issues/25494">https://github.com/facebook/react-native/issues/25494</a>. The stack-trace is identical to what we are observing, see <a href="https://github.com/facebook/react-native/issues/25494#issuecomment-514976930">https://github.com/facebook/react-native/issues/25494#issuecomment-514976930</a>.

There are two options discussed in the RN community as a workaround.
1) Use JSC with JIT disabled: We tried this option but this has great performance impact that we cannot deploy in the field.
2) Use RN 0.60.x with Hermes: The current version of RN 0.60.x comes with its own stability issues and until those get resolved, we cannot move to RN 0.60.

We contacted ARM since this crash is specific to arm64 and happening across multiple devices. We got the following response:
“We had a few engineers looking at this and we do not see an obvious pattern. There is a mixture of CPUs ranging from A53 only to “big/little” multi-core systems using A53, A55, A73, A75, A76, and M4. Our open source software engineers primarily work on the V8 JS engine so, we looked for similar issues fixed there and it does not look like something we have fixed previously. 

Given the problem is across so many disparate devices, our engineers suspect missing barriers, cache maintenance, or both in the generated code. These are the first areas, along with CPU detection (since it only seems to occur on Arm), where we would examine if we had better knowledge of JSC. I hope this helps you frame the issue for the bug report.”


Thanks for your support,
Pratik Patel</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>