Crash in arm x64
DanielZlotin opened this issue · comments
Running on a custom compiled react-native based on 0.51.0 version for x64 Android.
Once the bundle is loaded about 50% of times crashes with:
libc F Fatal signal 11 (SIGSEGV), code 1, fault addr 0x100000008 in tid 2215 (mqt_js), pid 2168 (wix.android.dev)
DEBUG F *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F Build fingerprint:
F Revision: '0'
F ABI: 'arm64'
F pid: 2168, tid: 2215, name: mqt_js >>> com.wix.android.dev <<<
F signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x100000008
F x0 0000007c6789c0a0 x1 0000007c68000000 x2 0000007c678cb258 x3 0000007c6caf7ee8
F x4 0000000000000000 x5 0000000000000000 x6 0000000000000000 x7 0000000000000000
F x8 0000000000000530 x9 0000000000000006 x10 0000000100000000 x11 0000000000000001
F x12 00000000cf1841c8 x13 0000000000000005 x14 000000000000007c x15 0000000000000001
F x16 0000000003010069 x17 0000000000000000 x18 0000000000000002 x19 0000007c6caf7ee8
F x20 0000007c68000000 x21 0000000000000000 x22 0000007c6789c0a0 x23 000000000301006a
F x24 000000000000007c x25 00000000cf1841c9 x26 0000000300000000 x27 0000007c61c27008
F x28 0000000000000002 x29 0000007c6caf8480 x30 0000007c6db57938
F sp 0000007c6caf7d80 pc 0000007c6db83294 pstate 0000000020000000
F backtrace:
F #00 pc 0000000000102294 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libjsc.so
F #01 pc 00000000000d6934 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libjsc.so
F #02 pc 00000000004e4474 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libjsc.so
F #03 pc 00000000004e4890 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libjsc.so
F #04 pc 00000000001d2fe4 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libjsc.so
F #05 pc 00000000003ac8bc /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libjsc.so
F #06 pc 000000000006601c /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libjsc.so (JSEvaluateScript+480)
F #07 pc 0000000000071f84 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libreactnativejni.so (facebook::react::evaluateScript(OpaqueJSContext const*, OpaqueJS
String*, OpaqueJSString*)+56)
F #08 pc 0000000000063a58 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libreactnativejni.so (facebook::react::JSCExecutor::loadApplicationScript(std::__ndk1:
:unique_ptr<facebook::react::JSBigString const, std::__ndk1::default_delete<facebook::react::JSBigString const>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>
, std::__ndk1::allocator<char>>)+632)
F #09 pc 000000000006dd00 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libreactnativejni.so
F #10 pc 000000000006eea0 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libreactnativejni.so
F #11 pc 0000000000034368 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libreactnativejni.so
F #12 pc 00000000000216cc /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libreactnativejni.so
F #13 pc 0000000000021648 /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/lib/arm64/libreactnativejni.so
F #14 pc 000000000003fa9c /data/app/com.wix.android.dev-mImsHlIhdjuBhFAgfqjh4g==/oat/arm64/base.odex (offset 0x39000)
I can't seem to reproduce it in our measure app, just in the Wix app (which is very big)
I reproduced it in the measure app. When running the benchmarks over and over again, once in about 20 runs I'm getting:
libc F Fatal signal 11 (SIGSEGV), code 1, fault addr 0xbbadbeef in tid 5920 (mqt_js), pid 5892 (ptcore.profiler)
DEBUG F *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F Build fingerprint: 'google/marlin/marlin:8.1.0/OPM4.171019.021.P1/4820305:user/release-keys'
F Revision: '0'
F ABI: 'arm64'
F pid: 5892, tid: 5920, name: mqt_js >>> com.javascriptcore.profiler <<<
F signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xbbadbeef
F x0 0000007c6dcf80b8 x1 0000007c6dcf80b8 x2 0000000000000000 x3 0000007c6dcf71f8
F x4 0000007c6efd9707 x5 0000007c6dcf79c1 x6 000000000000000a x7 000000000000000a
F x8 00000000bbadbeef x9 0000007c6efd9b56 x10 0000000000004001 x11 0000000000000000
F x12 0000007d06d0abe0 x13 0000000000000001 x14 0000000000000000 x15 0000000000000000
F x16 0000007d06d292c8 x17 0000007d06cc5a4c x18 0000000000000000 x19 0000007c6dcf81c0
F x20 0000007c6efd9706 x21 0000007c67c847a0 x22 0000007c660a6ad0 x23 0000007c67c84808
F x24 0000007c66e6ab00 x25 0000007c6dcf8180 x26 0000000000000000 x27 0000000000000001
F x28 ffff000000000002 x29 0000007c6dcf83c0 x30 0000007c6ef94530
F sp 0000007c6dcf80f0 pc 0000007c6ef94538 pstate 00000000a0000000
F backtrace:
F #00 pc 0000000000593538 /data/app/com.javascriptcore.profiler-MUBWpSsr4k51nt8yrR_9hA==/lib/arm64/libjsc.so
F #01 pc 0000000000504d88 /data/app/com.javascriptcore.profiler-MUBWpSsr4k51nt8yrR_9hA==/lib/arm64/libjsc.so
F #02 pc 0000000000505500 /data/app/com.javascriptcore.profiler-MUBWpSsr4k51nt8yrR_9hA==/lib/arm64/libjsc.so
F #03 pc 00000000005007f8 /data/app/com.javascriptcore.profiler-MUBWpSsr4k51nt8yrR_9hA==/lib/arm64/libjsc.so
F #04 pc 0000000000211b24 /data/app/com.javascriptcore.profiler-MUBWpSsr4k51nt8yrR_9hA==/lib/arm64/libjsc.so
F #05 pc 00000000000468fc <anonymous:0000007c697ff000>
This branch has the custom RN and configured app:
https://github.com/react-community/jsc-android-buildscripts/tree/RN51x64
Confirmed does not reproduce in arm x32 devices.
Also able to reproduce it in any clean RN app, just happens very rarely.
The device I used to run the test app without crashes is a Samsung Galaxy S2 (an ancient device with very low memory), so that sort of eliminates any concerns for out of memory errors. (the x64 device is a PixelXL)
Interesting to note: lowering the size of the bundle (by commenting out imports) makes the crash happen more rarely. Greatly lowering the bundle size (like in a clean new RN project) makes the crash onLoad about 1-5% of app starts.
Another possible factor could be differences between Android 7 and 8. Unfortunately I only have arm32 devices on 7 and arm64 on 8, so no cross validation. IIRC Android introduced different garbage collection algorithms and I wonder if this causes race conditions between Java and Javascript.
Another scenario for provoking a crash is creating large numbers of strings from Java into Javascript via JNI (using code based on https://github.com/ericwlange/AndroidJSCore), mainly stable on arm32/7, crashes reproducibly on arm64/8.
@mrueger42 Correct me if I'm wrong but I don't see how it relates to the Java GC. They don't share address space.
2 things I want to try:
- compile the same version of webkit as used in iOS 11.x (proved to be stable) - 2.19.2
- compile with symbols to better understand the cause of the crash
@DanielZlotin
I was building JSC with debug symbols using this patch https://gist.github.com/Kmakinator/9c6d23ab6c07b200ba9cf133fe5cbbba
It's month old now so it may not work on current master, it is also required to add doNotStrip not only to air building gradle but apk script. This allowed me to attach and set breakpoint using LLDB in android studio.
@DanielZlotin
Not sure about Java GC, it is just a hunch.
Also quite a bit out of my depth looking at the WebKit code base.
But, having said that, there is a lot of low level memory stuff going on in the context of strings. Java GC deciding to throw away something, WebKit code thinking it is still there, voila, null pointer exception.
Apologies for not being of much help on a technical level here.
A test on a non-arm64 device with Android 8 would help to prove/disprove that hunch.
And, thank you for maintaining this library btw!
Finding a phone with armv7a and android 8 is harder than I thought 😆
Hi, I've built JSC with debug symbols, and that's what I've got (Android 8.0):
Stack frame #00 pc 000000000076fed0 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (WTFCrash+48): Routine WTFCrash at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/WTF/wtf/Assertions.cpp:278
Stack frame #01 pc 000000000053d3b0 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZNK3WTF22HashTableConstIteratorINS_6RefPtrINS_17UniquedStringImplEEENS_12KeyValue: Routine WTF::HashTableConstIterator<WTF::RefPtr<WTF::UniquedStringImpl>, WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType> >, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType> > >, JSC::IdentifierRepHash, WTF::HashMap<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType>, JSC::IdentifierRepHash, WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> >, WTF::HashTraits<JSC::WriteBarrier<JSC::InferredType> > >::KeyValuePairTraits, WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> > >::checkValidity() const at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Debug/../../Source/WTF/wtf/HashTable.h:212
Stack frame #02 pc 000000000053d308 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3WTF22HashTableConstIteratorINS_6RefPtrINS_17UniquedStringImplEEENS_12KeyValueP: Routine WTF::HashTableConstIterator<WTF::RefPtr<WTF::UniquedStringImpl>, WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType> >, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType> > >, JSC::IdentifierRepHash, WTF::HashMap<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType>, JSC::IdentifierRepHash, WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> >, WTF::HashTraits<JSC::WriteBarrier<JSC::InferredType> > >::KeyValuePairTraits, WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> > >::operator++() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Debug/../../Source/WTF/wtf/HashTable.h:179
Stack frame #03 pc 000000000053d2d8 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3WTF17HashTableIteratorINS_6RefPtrINS_17UniquedStringImplEEENS_12KeyValuePairIS3_N3JSC12WriteBarrierINS5_12InferredTypeEEEEENS_24KeyValuePairKeyExtractorIS9_EENS5_17IdentifierRepHashENS_7HashMapIS3_S8_SC_NS_10HashTraitsIS3_EENSE_IS8_EEE18KeyValuePairTraitsESF_EppEv+20): Routine WTF::HashTableIterator<WTF::RefPtr<WTF::UniquedStringImpl>, WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType> >, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType> > >, JSC::IdentifierRepHash, WTF::HashMap<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType>, JSC::IdentifierRepHash, WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> >, WTF::HashTraits<JSC::WriteBarrier<JSC::InferredType> > >::KeyValuePairTraits, WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> > >::operator++() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Debug/../../Source/WTF/wtf/HashTable.h:265
Stack frame #04 pc 000000000053b72c /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3WTF24HashTableIteratorAdapterINS_9HashTableINS_6RefPtrINS_17UniquedStringImplEEENS_12KeyValuePairIS4_N3JSC12WriteBarrierINS6_12InferredTypeEEEEENS_24KeyValuePairKeyExtractorISA_EENS6_17IdentifierRepHashENS_7HashMapIS4_S9_SD_NS_10HashTraitsIS4_EENSF_IS9_EEE18KeyValuePairTraitsESG_EESA_EppEv+28): Routine WTF::HashTableIteratorAdapter<WTF::HashTable<WTF::RefPtr<WTF::UniquedStringImpl>, WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType> >, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType> > >, JSC::IdentifierRepHash, WTF::HashMap<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType>, JSC::IdentifierRepHash, WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> >, WTF::HashTraits<JSC::WriteBarrier<JSC::InferredType> > >::KeyValuePairTraits, WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> > >, WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>, JSC::WriteBarrier<JSC::InferredType> > >::operator++() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Debug/../../Source/WTF/wtf/HashIterators.h:74
Stack frame #05 pc 000000000053b308 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3JSC17InferredTypeTable13visitChildrenEPNS_6JSCellERNS_11SlotVisitorE+240): Routine JSC::InferredTypeTable::visitChildren(JSC::JSCell*, JSC::SlotVisitor&) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/JavaScriptCore/runtime/InferredTypeTable.cpp:59
Stack frame #06 pc 00000000002a8eac /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3JSC11SlotVisitor13visitChildrenEPKNS_6JSCellE+292): Routine JSC::SlotVisitor::visitChildren(JSC::JSCell const*) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/JavaScriptCore/heap/SlotVisitor.cpp:385
Stack frame #07 pc 00000000002aea8c /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+188): Routine operator() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/JavaScriptCore/heap/SlotVisitor.cpp:484
Stack frame #08 pc 00000000002a936c /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3JSC11SlotVisitor16forEachMarkStackIZNS0_5drainEN3WTF13MonotonicTimeEE3$_3EENS_15IterationStatusERKT_+36): Routine JSC::IterationStatus JSC::SlotVisitor::forEachMarkStack<JSC::SlotVisitor::drain(WTF::MonotonicTime)::$_3>(JSC::SlotVisitor::drain(WTF::MonotonicTime)::$_3 const&) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Debug/../../Source/JavaScriptCore/heap/SlotVisitorInlines.h:173
Stack frame #09 pc 00000000002a92d8 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeE+164): Routine JSC::SlotVisitor::drain(WTF::MonotonicTime) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/JavaScriptCore/heap/SlotVisitor.cpp:474
Stack frame #10 pc 00000000002a9c5c /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3JSC11SlotVisitor15drainFromSharedENS0_15SharedDrainModeEN3WTF13MonotonicTimeE+840): Routine JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/JavaScriptCore/heap/SlotVisitor.cpp:653
Stack frame #11 pc 0000000000278164 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZZN3JSC4Heap13runBeginPhaseENS_11GCConductorEENK4$_10clEv+664): Routine operator() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/JavaScriptCore/heap/Heap.cpp:1223
Stack frame #12 pc 0000000000277ebc /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_10E3runEv+20): Routine WTF::SharedTaskFunctor<void (), JSC::Heap::runBeginPhase(JSC::GCConductor)::$_10>::run() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Debug/../../Source/WTF/wtf/SharedTask.h:90
Stack frame #13 pc 0000000000783be4 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3WTF20ParallelHelperClient7runTaskENS_6RefPtrINS_10SharedTaskIFvvEEEEE+148): Routine WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()> >) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/WTF/wtf/ParallelHelperPool.cpp:112
Stack frame #14 pc 0000000000784754 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3WTF18ParallelHelperPool6Thread4workEv+52): Routine WTF::ParallelHelperPool::Thread::work() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/WTF/wtf/ParallelHelperPool.cpp:194
Stack frame #15 pc 0000000000772110 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZZN3WTF15AutomaticThread5startERKNS_14AbstractLockerEENK3$_0clEv+548): Routine operator() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/WTF/wtf/AutomaticThread.cpp:222
Stack frame #16 pc 0000000000771e54 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+20): Routine WTF::Function<void ()>::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0>::call() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Debug/../../Source/WTF/wtf/Function.h:101
Stack frame #17 pc 0000000000779d50 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZNK3WTF8FunctionIFvvEEclEv+140): Routine WTF::Function<void ()>::operator()() const at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Debug/../../Source/WTF/wtf/Function.h:56
Stack frame #18 pc 000000000078ff70 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3WTF6Thread10entryPointEPNS0_16NewThreadContextE+312): Routine WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/WTF/wtf/Threading.cpp:129
Stack frame #19 pc 00000000007b8048 /data/app/com.javascriptcore.profiler-TDTbnfycx4q0a_uzxFtyKw==/lib/arm64/libjsc.so (_ZN3WTFL19wtfThreadEntryPointEPv+16): Routine WTF::wtfThreadEntryPoint(void*) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/WTF/wtf/ThreadingPthreads.cpp:228
Stack frame #20 pc 00000000000667d0 /system/lib64/libc.so (_ZL15__pthread_startPv+36)
Stack frame #21 pc 000000000001f2a4 /system/lib64/libc.so (__start_thread+68)
After some digging, it looks like some kind of race condition: some iterators get invalidated while they're being used. Looking further, we have ENABLE_DFG_JIT=0, which (according to Platform.h) makes ENABLE_CONCURRENT_JS=0, which in turn makes everything use dymmy NoLock implementation for locking. We still have no idea why JSC without DFG would require locking, but after patching Platform.h to set ENABLE_CONCURRENT_JS=1 for all 64bit builds apparently fixes the crash. We also are not sure why 32bit build is fine and 64bit has this crash, however there are some JIT-specific files that have significant amount of code depend on architecture.
I'll submit a pull request after I do some more tests. So far after ~100 runs no crashes.
Edit: release build crashes still.
After adding debug symbols to release build, I get this stacktrace for the crash:
********** Crash dump: **********
Build fingerprint: 'Sony/G8441/G8441:8.0.0/47.1.A.12.270/1908755578:user/release-keys'
pid: 1999, tid: 2027, name: mqt_js >>> com.javascriptcore.profiler <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xbbadbeef
Stack frame #00 pc 00000000004fb3dc /data/app/com.javascriptcore.profiler-BdcsWroJ55AherG3x0OehQ==/lib/arm64/libjsc.so (WTFCrash+32): Routine WTFCrash at /home/pm/git/jsc-android-buildscripts/build/target/webkit/Source/WTF/wtf/Assertions.cpp:278
Stack frame #01 pc 00000000004ae37c /data/app/com.javascriptcore.profiler-BdcsWroJ55AherG3x0OehQ==/lib/arm64/libjsc.so (_ZL24UNREACHABLE_FOR_PLATFORMv+4): Routine UNREACHABLE_FOR_PLATFORM() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Release/../../Source/WTF/wtf/Assertions.h:473
Stack frame #02 pc 00000000004aeaf4 /data/app/com.javascriptcore.profiler-BdcsWroJ55AherG3x0OehQ==/lib/arm64/libjsc.so (_ZZNK3JSC9Structure22checkOffsetConsistencyIZNS0_24materializePropertyTableERNS_2V: Routine operator() at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Release/../../Source/JavaScriptCore/runtime/StructureInlines.h:270
Stack frame #03 pc 00000000004a9fcc /data/app/com.javascriptcore.profiler-BdcsWroJ55AherG3x0OehQ==/lib/arm64/libjsc.so (_ZN3JSC9Structure24materializePropertyTableERNS_2VMEb+1020): Routine bool JSC::Structure::checkOffsetConsistency<JSC::Structure::materializePropertyTable(JSC::VM&, bool)::$_0>(JSC::PropertyTable*, JSC::Structure::materializePropertyTable(JSC::VM&, bool)::$_0 const&) const at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Release/../../Source/JavaScriptCore/runtime/StructureInlines.h:274
Stack frame #04 pc 00000000001eb664 /data/app/com.javascriptcore.profiler-BdcsWroJ55AherG3x0OehQ==/lib/arm64/libjsc.so (operationGetById+472): Routine JSC::Structure::ensurePropertyTableIfNotEmpty(JSC::VM&) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Release/../../Source/JavaScriptCore/runtime/Structure.h:677
Stack frame #05 pc 00000000000458e0 <anonymous:000000709a1ff000>
Great work @pmlocek thank you.
Is this the same crash? doesn't look like it...
Another update: I've disabled concurrent GC and it seems to be stable again. I'll also try disabling concurrent JIT, as it might have less impact than disabling concurrent GC.
@DanielZlotin Note that the options we now are trying to disable (concurrentGC and concurrentJIT) are OFF on 32bit builds and only configured to be ON by default on 64bit platforms.
OK so after playing around with the source I discovered a few interesting things:
- It appears that compiling JSC with current scripts uses the local machine's CPU architecture rather than cross-compiling to arm. This can cause all sorts of problems, and it's actually surprising to me that current published JSC we use works fine. Maybe I'm wrong about this but following the breadcrumbs from here shows that arch is detected in the cmake scripts rather than injected as a parameter. This is what caused building newer JSC to crash in compile time with
no magic numbers found for offline asmdue toOFFLINE_ASM_BACKENDbeing equal to"ARMv7_TRADITIONAL"instead ofARM64 - It appears JSC has at least 1 bug manifesting in Cortex-A53 microarchritecture (a lot of x64 phones) and the way they "fixed" it is by doing a
#if(CPU....directive and injecting some opcodes to the LLInt (specifically I'm talking about this bug), which means this is compile-time evaluated. Which means that if we want to correctly handle this fix, we should have at least 3 JSC compiled.. one for Cortex-A53 ARM-V8A procs, one for all other x64 procs, one for x32 procs. At least. This is bad news, I'm not sure where to go from here. Looking at this specific bug we might be fine with using the "fixed" version for all x64 devices because the fix is simply adding 2 moreno-ops.. I'll try it in the coming week and see what gives. see here for more info
What is the impact of Concurrent GC on performance?
Not related to the crash (yet) but I found that the scripts should pass the compiler as an ENV argument in order for the webkit scripts to accept the build as a cross compile build, and also the -DCMAKE_SYSTEM_PROCESSOR should be aarch64 (and not arm64) when building for arm64, otherwise incorrect CPU is detected by cmake, breaking compilation with no magic numbers found for offline asm. The detection is happening here
Using the above approach greatly lessens the crash rate but it still happens. I'll add symbols to see if it's the same crash.
Adding debug symbols (-g in cxx flags) and it's not crashing anymore. What 😖
Today we got following crash on a build with no concurrent GC:
pid: 14583, tid: 14609, name: mqt_js >>> com.javascriptcore.profiler <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x180000000141
Stack frame #00 pc 00000000000a5f48 /data/app/com.javascriptcore.profiler-i1rEYR3_AtzMLTpK8Utspw==/lib/arm64/libjsc.so (JSC::Structure::didReplaceProperty(int)+92): Routine bool WTF::IdentityHashTranslator<WTF::HashMap<int, WTF::RefPtr<JSC::WatchpointSet>, WTF::IntHash<int>, WTF::UnsignedWithZeroKeyHashTraits<int>, WTF::HashTraits<WTF::RefPtr<JSC::WatchpointSet> > >::KeyValuePairTraits, WTF::IntHash<int> >::equal<int, int>(int const&, int const&) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Release/../../Source/WTF/wtf/HashTable.h:284
Stack frame #01 pc 00000000001ff768 /data/app/com.javascriptcore.profiler-i1rEYR3_AtzMLTpK8Utspw==/lib/arm64/libjsc.so (_ZN3JSC8JSObject17putDirectInternalILNS0_7PutModeE0EEEbRNS_2VMENS_12PropertyNameEN: Routine bool JSC::JSObject::putDirectInternal<(JSC::JSObject::PutMode)0>(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int, JSC::PutPropertySlot&) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Release/../../Source/JavaScriptCore/runtime/JSObjectInlines.h:319
Stack frame #02 pc 00000000001ef408 /data/app/com.javascriptcore.profiler-i1rEYR3_AtzMLTpK8Utspw==/lib/arm64/libjsc.so (operationPutByIdStrict+920): Routine JSC::JSObject::putInlineForJSObject(JSC::JSCell*, JSC::ExecState*, JSC::PropertyName, JSC::JSValue, JSC::PutPropertySlot&) at /home/pm/git/jsc-android-buildscripts/build/target/webkit/WebKitBuild/Release/../../Source/JavaScriptCore/runtime/JSObjectInlines.h:216
Stack frame #03 pc 000000000004ff38 <anonymous:0000007b8c3ff000>```
Another possible lead: we've noticed a lot of the code around the place where the crash happens is inlined, so it's difficult to debug. So we've decided to disable inlining in Clang, to make debugging easier. So far, the build with no inlining didn't crash after running 3200 tests.
@pmlocek wow that's an amazing catch! What is controlling the inlining? I want to check it out myself and see if we can live with the perf/size hit
@DanielZlotin
So far we've gone all-in and just appended -fno-inline compiler flag to CFLAGS. There might be some option to manipulate inlining by allowing only hinted functions to get inlined (-inline-hint-functions), or changing inlining threshold. Size seems to be lower than with inlined version. We've only tested performance impact on rendering tests, and it seems within 10% of inlined version. Currently we're testing if DFG and FTL JIT will work now.
@pmlocek did you find an easy way to reproduce the crash? I'm not able to reproduce it in the measure app no matter what I do now, just in the actual Wix app :\
We're running measure app without 'Profile Javascript' and it usually crashes within 200 runs.
Damn was hoping you found something quicker 😕
Great success! (well.. a small step)
Managed to reproduce the crash consistently on this branch by bundling lots of code.
npm install from ./measure/ and then call npm run android
Thanks, that'll be a great help. That manages to produce the crash every time the app bundle loads?
About 50% of the app launches
Update: managed to build with symbols and got this stacktrace:
F Revision: '0'
F ABI: 'arm64'
F pid: 14560, tid: 14581, name: mqt_js >>> com.javascriptcore.profiler <<<
F signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x100000008
F x0 000000742dda40a0 x1 000000742e500000 x2 000000742ddcb398 x3 0000007432bfce28
F x4 0000000000000000 x5 0000000000000004 x6 0000000100000001 x7 0000000100000001
F x8 0000000000000008 x9 0000000000000006 x10 0000000100000000 x11 0000000000000001
F x12 000000005bb8c1c8 x13 0000000000000005 x14 0000000000000074 x15 0000000000000001
F x16 0000000003010063 x17 00000074ce75eff0 x18 0000000000120000 x19 0000007432bfce28
F x20 000000742e500000 x21 0000000000000000 x22 000000742dda40a0 x23 0000000003010064
F x24 0000000000000074 x25 000000005bb8c1c9 x26 0000000100000000 x27 000000742782e008
F x28 0000000000000002 x29 0000007432bfd3c0
F sp 0000007432bfccc0 lr 0000007433851a70 pc 000000743386e344
F backtrace:
F #00 pc 00000000001aa344 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libjsc.so (JSC::UnlinkedFunctionExecutable::link(JSC::VM&, JSC::SourceCode const&, std::optional<int>, JSC::Intrinsic)+124)
F #01 pc 000000000018da6c /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libjsc.so (JSC::CodeBlock::finishCreation(JSC::VM&, JSC::ScriptExecutable*,JSC::UnlinkedCodeBlock*, JSC::JSScope*)+1832)
F #02 pc 000000000052f8b4 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libjsc.so (JSC::ScriptExecutable::newCodeBlockFor(JSC::CodeSpecializationKind, JSC::JSFunction*, JSC::JSScope*, JSC::JSObject*&)+784)
F #03 pc 000000000052fb1c /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libjsc.so (JSC::ScriptExecutable::prepareForExecutionImpl(JSC::VM&, JSC::JSFunction*, JSC::JSScope*, JSC::CodeSpecializationKind, JSC::CodeBlock*&)+232)
F #04 pc 00000000002366ac /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libjsc.so (JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::ExecState*, JSC::JSObject*)+11260)
F #05 pc 00000000003f3e64 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libjsc.so (JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)+316)
F #06 pc 0000000000123d9c /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libjsc.so (JSEvaluateScript+480)
F #07 pc 0000000000071f84 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libreactnativejni.so (facebook::react::evaluateScript(OpaqueJSContext const*, OpaqueJSString*, OpaqueJSString*)+56)
F #08 pc 0000000000063a58 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libreactnativejni.so (facebook::react::JSCExecutor::loadApplicationScript(std::__ndk1::unique_ptr<facebook::react::JSBigString const, std::__ndk1::default_delete<facebook::react::JSBigString const>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>)+632)
F #09 pc 000000000006dd00 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libreactnativejni.so
F #10 pc 000000000006eea0 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libreactnativejni.so
F #11 pc 0000000000034368 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libreactnativejni.so
F #12 pc 00000000000216cc /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libreactnativejni.so
F #13 pc 0000000000021648 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/lib/arm64/libreactnativejni.so
F #14 pc 0000000000011cbc /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/oat/arm64/base.odex (offset 0x11000) (com.facebook.jni.Countable.dispose [DEDUPED]+124)
F #15 pc 0000000000aaa4ac /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (android.os.Handler.dispatchMessage+76)
F #16 pc 0000000000560388 /system/lib64/libart.so (art_quick_invoke_stub+584)
F #17 pc 00000000000cf6b8 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
F #18 pc 0000000000282afc /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344)
F #19 pc 000000000027cbac /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+960)
F #20 pc 000000000053013c /system/lib64/libart.so (MterpInvokeSuper+1396)
F #21 pc 0000000000552a14 /system/lib64/libart.so (ExecuteMterpImpl+14356)
F #22 pc 00000000001a4098 /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/oat/arm64/base.vdex (com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage)
F #23 pc 0000000000256d0c /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3442999494+488)
F #24 pc 0000000000520284 /system/lib64/libart.so (artQuickToInterpreterBridge+944)
F #25 pc 00000000005694fc /system/lib64/libart.so (art_quick_to_interpreter_bridge+92)
F #26 pc 0000000000aad610 /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (android.os.Looper.loop+1264)
F #27 pc 000000000056064c /system/lib64/libart.so (art_quick_invoke_static_stub+604)
F #28 pc 00000000000cf6d8 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+232)
F #29 pc 0000000000282afc /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344)
F #30 pc 000000000027cbac /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+960)
F #31 pc 0000000000530f84 /system/lib64/libart.so (MterpInvokeStatic+200)
F #32 pc 0000000000552b14 /system/lib64/libart.so (ExecuteMterpImpl+14612)
F #33 pc 00000000001a41ac /data/app/com.javascriptcore.profiler-yepfavdiHRM5eQaPVc5lUQ==/oat/arm64/base.vdex (com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run+32)
F #34 pc 0000000000256d0c /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3442999494+488)
F #35 pc 0000000000520284 /system/lib64/libart.so (artQuickToInterpreterBridge+944)
F #36 pc 00000000005694fc /system/lib64/libart.so (art_quick_to_interpreter_bridge+92)
F #37 pc 000000000025cf88 /system/framework/arm64/boot.oat (offset 0x114000) (java.lang.Thread.run+72)
F #38 pc 0000000000560388 /system/lib64/libart.so (art_quick_invoke_stub+584)
F #39 pc 00000000000cf6b8 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
F #40 pc 00000000004661e4 /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
F #41 pc 00000000004672e8 /system/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue*)+424)
F #42 pc 0000000000492660 /system/lib64/libart.so (art::Thread::CreateCallback(void*)+1116)
F #43 pc 00000000000847bc /system/lib64/libc.so (__pthread_start(void*)+36)
F #44 pc 0000000000023574 /system/lib64/libc.so (__start_thread+68)
Doesn't look like the same stacktrace you guys got.. I'll try with -fno-inline in CFLAGS, and force a debuggable build with APP_OPTIM := debug
Hi @DanielZlotin , is this crash specific to RN 0.51? We were hoping to use the new JSC in our project but we currently use 0.51.
Hi, I was trying to debug this issue and so far I found two ways that are partially fixing the problem.
- fix for 2.18.2
I ran benchmarks for few days about 10k app restarts and it crashed once.
- changing arm64 to aarch64 in
-DCMAKE_SYSTEM_PROCESSOR=$ARCH_NAME - WebKit/WebKit@900724c
- updating to 2.22.2
For now, I tested the new version with ARCH_NAME=aarch64 and some patches changes(mostly files moved between directories or line changes caused by modifications in other parts of the file). 5k restarts for now and no crashes yet.
When I benchmark build I usually add sleep after launchProfiler and after killProfiler otherwise, sometimes adb command to click happens to early and benchmark is blocked waiting for sth that won't happen. It shouldn't affect crash directly but it changes whether a device is under heavy load and it may make start off the app more deterministic and potential race could always end with the same effect without a crash.
The direct reason for a crash is gc issue, for a crash with stacktrace ending with UnlinkedFunctionExecutable::link reason was that command allocateCell while allocating memory for ProgramCodeBlock was returning memory already used by another object.
Internally in gc there are MarkedAllocator objects that have MarkedBlocks that are essentially some memory fragments, every allocator has few bit vectors that represents a state of those blocks.
When a crash occurs one allocator is "stealing" block from another one. When I log operations on that block(before stealing) I see when a block was allocated, I see where block is set not empty and later while it's stolen by another allocator it's already marked as empty but setter for that block was never called.
It's possible that I missed something there and the problem is deeper. I suspect that there is some race condition and fixes like disable inlining are masking this race by slowing down certain part fo code, also there are some cases where locking is optional depending on build and platform that may explain way arm64 is the only platform where this occurs.
@rajivshah3 happens on newer RN as well. It's not related to RN at all it seems, something with JSC+arm64. If you use the 32 version you should be fine.
@wkozyra95 Thanks for that! Passing the correct arch looks to be unrelated to the crash directly, but fixes other build issues according to #55 . Looking forward to hearing if still crashes in 2.22.2
FYI I'm no longer actively maintaining this project but will help as best I can
After over 20k restarts version 2.22.2 didn't crash, so I'm assuming that the issue is fixed there. I prepared PR with required changes.
🎉
@DanielZlotin This crash produced in version 225067.0.0! I upgrade version to 236355.1.1, still crash!
stack info:
Build fingerprint: 'OnePlus/OnePlus5/OnePlus5:9/PKQ1.180716.001/1901211819:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 21088, tid: 21262, name: mqt_js >>> com...* <<<
signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0xcdbad6b0
r0 bbadbeef r1 00000000 r2 00000003 r3 00004022
r4 20000010 r5 ce6a2b8c r6 cdd4dd04 r7 0000001c
r8 ccb472f0 r9 ccb471d8 r10 ccb471d8 r11 ccb47230
ip f226960c sp ccb46ee8 lr f220f189 pc cdbad6b0
backtrace:
#00 pc 005e76b0 /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#1 pc 005e47cb /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#2 pc 00577e7f /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#3 pc 00584e1b /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#4 pc 00584325 /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#5 pc 00584b4b /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#6 pc 00462187 /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#7 pc 004638d7 /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#8 pc 00462379 /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#9 pc 004615bb /data/app/com...-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
#10 pc 004660c5 /data/app/com...*-QGRm-TJmVBsK5BRESj2EPg==/lib/arm/libjsc.so (offset 0x68000)
hey @luoyushouchai ! Would you be able to provide repro steps for the crash you posted? I'd also appreciate if you decided to open a new issue for your crash as based on the stacktrace you posted it appears like it happens on ARMv7 and not ARM64 (which this issue was all about)
Hi @wkozyra95 I'm having all sorts of unpredictable and intermittent crashes trying to build a release version of my Android RN project. I usually don't get any stack trace at all but the last time it gave me the following. Is it related to the problem you're discussing here? I'm afraid the chat is way over my head but it seemed like the fix was "changing arm64 to aarch64 in DCMAKE_SYSTEM_PROCESSOR=$ARCH_NAME". Where exactly do I set that? Thanks
--------- beginning of crash
02-01 18:58:07.160 10781 10839 F libc : Fatal signal 4 (SIGILL), code 1, fault addr 0x7a88050ae0 in tid 10839 (mqt_js)
02-01 18:58:07.272 10849 10849 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
02-01 18:58:07.272 10849 10849 F DEBUG : Build fingerprint: 'samsung/heroltexx/herolte:7.0/NRD90M/G930FXXU2DRB6:user/release-keys'
02-01 18:58:07.272 10849 10849 F DEBUG : Revision: '8'
02-01 18:58:07.272 10849 10849 F DEBUG : ABI: 'arm64'
02-01 18:58:07.273 10849 10849 F DEBUG : pid: 10781, tid: 10839, name: mqt_js >>> com.aupanda.AuPanda <<<
02-01 18:58:07.273 10849 10849 F DEBUG : signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x7a88050ae0
02-01 18:58:07.273 10849 10849 F DEBUG : x0 0000007a87f35a34 x1 0000000000000000 x2 00000000000000f8 x3 0000007a964fbda0
02-01 18:58:07.273 10849 10849 F DEBUG : x4 0000007a88050ae0 x5 0000000000000000 x6 00000000e674603f x7 0000007a877f86e0
02-01 18:58:07.273 10849 10849 F DEBUG : x8 0000007a964fe848 x9 0000000000000001 x10 0000000000000001 x11 0000007a88050bc0
02-01 18:58:07.273 10849 10849 F DEBUG : x12 0000000000000007 x13 0000000000000108 x14 0000000000000004 x15 0000000000000001
02-01 18:58:07.273 10849 10849 F DEBUG : x16 0000007a96cee110 x17 0000007abc5e9dc4 x18 000000000000007b x19 0000007a964fbda0
02-01 18:58:07.273 10849 10849 F DEBUG : x20 0000007a85932df0 x21 0000007a964fbd90 x22 0000007a964fbd78 x23 0000000000000000
02-01 18:58:07.273 10849 10849 F DEBUG : x24 0000000000000000 x25 0000007a858cbd80 x26 0000000000000001 x27 0000007a964fbd78
02-01 18:58:07.273 10849 10849 F DEBUG : x28 0000007a85932df0 x29 0000007a964fbe20 x30 0000007a96b85c9c
02-01 18:58:07.273 10849 10849 F DEBUG : sp 0000007a964fbcb0 pc 0000007a88050ae0 pstate 0000000060000000
02-01 18:58:07.277 10849 10849 F DEBUG :
02-01 18:58:07.277 10849 10849 F DEBUG : backtrace:
02-01 18:58:07.277 10849 10849 F DEBUG : #00 pc 0000000000051ae0 <anonymous:0000007a87fff000>
02-01 18:58:07.277 10849 10849 F DEBUG : #01 pc 00000000002f7c98 /data/app/com.aupanda.AuPanda-1/lib/arm64/libjsc.so (_ZN3JSC6RegExp5matchERNS_2VMERKN3WTF6StringEjRNS3_6VectorIiLm32ENS3_15CrashOnOverflowEEE+348)
02-01 18:58:07.278 10849 10849 F DEBUG : #02 pc 0000000000309654 /data/app/com.aupanda.AuPanda-1/lib/arm64/libjsc.so
aarch64 issue is already handled here https://github.com/react-native-community/jsc-android-buildscripts/blob/master/scripts/compile/jsc.sh#L37 If arm64 is set as ARCH_NAME aarch64 will be passed to cmake build. I'm not exactly certain that this problem was related to the fix.
If you are using the latest jsc it's probably a different bug. This crash happened maybe once per hundred app lunches (only on start), fault address usually had a lot of zeros (garbage collector issue allocated two objects in the same place in memory and code accessing those fragments was potentially reading random stuff). Simplest fix we found was to disable code inlining (it was to large perfomance drop to use that solution), you can try that.