App Crash on Android OS 6 Samsung Galaxy S7 SM-G930FD (JSC Crash) 64 bit support A/libc: Fatal signal 11 (SIGSEGV)

Question

App Crash on Android OS 6 Samsung Galaxy S7 SM-G930FD (JSC Crash) 64 bit support A/libc: Fatal signal 11 (SIGSEGV)

dishantwalia opened this issue 6 years ago · 190 comments

Bug Report
Crashed on launch
Crashed with only this error log traced on android logcat A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 20217.

To Reproduce
react-native run-android
and navigate to second screen from initial route through stack navigator. I am using React-Navigation 3.6
App crashes as soon as I start going into react-navigation and crashing in Samsung S7 64 bit CPU device, working fine in other android devices which I am using.

Expected Behavior
just to work in a stable manner. like in earlier react-native version 0.58

Environment
React Native Environment Info:
System:
OS: Mac OS mojave 10.14
Binaries:
npm: 6.4.1
Android Studio: Version 3.2.1
Android 6.0.1 (real device: Samsung S7 SM-G930FD)
React Native v0.59.3

Temporary Workaround:
When I removed 64 bit ndk filters "arm64-v8a", "x86_64" from ndk abiFilters in defaultConfig block of buidl.gradle by provide only 32 bit support.
It works fine.

 ndk {
            abiFilters "armeabi-v7a", "x86", "arm64-v8a", "x86_64"  -> change to
            abiFilters "armeabi-v7a", "x86"
        }```

dishantwalia commented 6 years ago

#25060

Answer 1 · 2019-04-02T13:15:08.000Z

Thanks for submitting your issue. Can you take another look at your description and make sure the issue template has been filled in its entirety?

👉 Click here if you want to take another look at the Bug Report issue template.

Answer 2 · 2019-04-03T11:59:37.000Z

Thanks for submitting your issue. Can you take another look at your description and make sure the issue template has been filled in its entirety?

👉 Click here if you want to take another look at the Bug Report issue template.

Updated

Answer 3 · 2019-04-03T12:11:07.000Z

Logcat Error Screenshot for reference

Answer 4 · 2019-04-07T04:19:38.000Z

publishing 64bit split build I'm also getting this crash on launch on Galaxy S7 & Galaxy S7 Edge with Android 7.0
android vitals showing:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) WTFCrash
backtrace:
#00 pc 00000000007e048c /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (WTFCrash+16)
#1 pc 00000000000be650 /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i+24)
#2 pc 0000000000489f2c /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
#3 pc 000000000019e27c

on Crashlytics for those devices I'm getting:
Fatal Exception: com.facebook.react.common.c
Invariant Violation: Resuming work not yet implemented.

the workaround of only providing 32bit build is solving this for now

Answer 5 · 2019-04-08T09:58:51.000Z

I'm seeing the exact same errors as @nadavmos on Galaxy S7 running Android 7.0. The app is crashing at startup

Answer 6 · 2019-04-08T10:07:45.000Z

I'm seeing the exact same errors as @nadavmos on Galaxy S7 running Android 7.0. The app is crashing at startup

@nsantacruz are you also using react-navigation? seems common to all other reporters

Answer 7 · 2019-04-08T10:12:01.000Z

@nadavmos, I'm not using react-navigation. This very well maybe the same issue as #24260 since that issue is also affecting 0.59 with Samsung S7 on Android 7.0

Answer 8 · 2019-04-08T10:12:21.000Z

@nadavmos The crash is not related to react-navigation, in-fact the app is crashing on a fresh RN Project created via react-native init.

Answer 9 · 2019-04-09T01:41:11.000Z

@hramos @mkonicek As of now we can conclude that this seems to be an issue with latest RN 0.59 release, affecting android builds running on Samsung S7, S7 Edge after we provided support for arm64-v8a, x86_64, removing them from build.gradle does not crash the app, which could potentially affect apps going live after 1 August 2019 as per Google Play 64 bit support policy. We would like you guys to draw some attention to it, please?

Answer 10 · 2019-04-11T10:14:05.000Z

Also happening on 0.58.5. Galaxy S7. Android 6.0. Setting it to 32 bit build is also not working.

Answer 11 · 2019-04-15T15:13:37.000Z

We're observing the same crashes on 64 bit builds of RN 0.59.4 on a Galaxy S7 running Android 7.0. Sadly we don't have access to that model of device. It works fine on all of ours.

Answer 12 · 2019-04-15T18:06:22.000Z

Having the same issue with Huawai P9 device under the following environment:

  React Native Environment Info:
    System:
      OS: macOS 10.14.3
      CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
      Memory: 63.57 MB / 32.00 GB
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 11.3.0 - /usr/local/bin/node
      Yarn: 1.12.3 - /usr/local/bin/yarn
      npm: 6.9.0 - /usr/local/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
      Android SDK:
        API Levels: 23, 26, 27, 28
        Build Tools: 23.0.1, 25.0.0, 26.0.3, 27.0.3, 28.0.1, 28.0.2, 28.0.3
        System Images: android-24 | Google APIs Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom
    IDEs:
      Android Studio: 3.2 AI-181.5540.7.32.5056338
      Xcode: 10.2/10E125 - /usr/bin/xcodebuild
    npmPackages:
      react: ^16.8.3 => 16.8.3
      react-native: ^0.59.4 => 0.59.4
    npmGlobalPackages:
      eslint-plugin-react-native: 3.5.0
      react-native-cli: 2.0.1
      react-native-git-upgrade: 0.2.7

This is the Crashlytics stack trace we get:


# Platform: android
# Issue ID: 5beec130f8b88c29632f185d
# Session ID: 5cb483b90037000127d26eeee3e996f5_DNE_0_v2
# Date: 2019-04-15T13:15:00Z
# OS Version: 7.0
# Device: PRA-LX1
# RAM Free: 1.3%
# Disk Free: 14.3%

#0. Crashed: Thread
0  (Missing)                              0xc00d9b20 (Missing)
1  (Missing)                              0x3ffffffd (Missing)
2  libc.so                                0xeda60d64 (Missing)
3  (Missing)                              0x3fdec95c (Missing)
4  libc.so                                0xeda3223f (Missing)
5  libutils.so                            0xee283df1 (Missing)
6  (Missing)                              0xea6ac55a (Missing)
7  libart.so                              0xebc85331 (Missing)
8  (Missing)                              0x12dfd11e (Missing)
9  (Missing)                              0x12da927e (Missing)
10 system@framework@boot-framework.oat    0x74d6de0d (Missing)
11 (Missing)                              0x3fdec95c (Missing)
12 (Missing)                              0x12f39976 (Missing)
13 (Missing)                              0x12c2064e (Missing)
14 (Missing)                              0x70e43ada (Missing)
15 (Missing)                              0x12f43b8e (Missing)
16 libart.so                              0xebc85331 (Missing)
17 (Missing)                              0x70d268be (Missing)
18 system@framework@boot.oat              0x716279db (Missing)
19 (Missing)                              0x70837262 (Missing)
20 (Missing)                              0x70190306 (Missing)
21 (Missing)                              0x2cb6ab0c (Missing)
22 (Missing)                              0x70d58d82 (Missing)
23 (Missing)                              0x2cb6ab0c (Missing)
24 (Missing)                              0x2cb6ab0c (Missing)
25 (Missing)                              0x70c63cee (Missing)
26 (Missing)                              0x12c2064e (Missing)
27 (Missing)                              0x70e43ada (Missing)
28 (Missing)                              0x12f43c1e (Missing)
29 libart.so                              0xebca3526 (Missing)
30 (Missing)                              0x3fdec95c (Missing)
31 (Missing)                              0x70e43ada (Missing)
32 (Missing)                              0x70e43ada (Missing)
33 (Missing)                              0x12f39976 (Missing)
34 (Missing)                              0x12f43b8e (Missing)
35 libart.so                              0xebc85331 (Missing)
36 (Missing)                              0x70d268e2 (Missing)
37 (Missing)                              0x3fdec95c (Missing)
38 libutils.so                            0xee283ced (Missing)
39 (Missing)                              0x70abe4f6 (Missing)
40 (Missing)                              0x70aadb2e (Missing)
41 libandroid_runtime.so                  0xecdb23ff (Missing)
42 (Missing)                              0x70abe4f6 (Missing)
43 (Missing)                              0x12c2fa8e (Missing)
44 system@framework@boot-framework.oat    0x749d1865 (Missing)
45 (Missing)                              0x12c2fa8e (Missing)
46 system@framework@boot-framework.oat    0x741f0347 (Missing)
47 (Missing)                              0x70d3b9ca (Missing)
48 (Missing)                              0x12c2fa8e (Missing)
49 (Missing)                              0x12c2fa8e (Missing)
50 (Missing)                              0x70abe4f6 (Missing)
51 (Missing)                              0x70aadb2e (Missing)

--

#0. Crashed: Thread
0  (Missing)                              0xc00d9b20 (Missing)
1  (Missing)                              0x3ffffffd (Missing)
2  libc.so                                0xeda60d64 (Missing)
3  (Missing)                              0x3fdec95c (Missing)
4  libc.so                                0xeda3223f (Missing)
5  libutils.so                            0xee283df1 (Missing)
6  (Missing)                              0xea6ac55a (Missing)
7  libart.so                              0xebc85331 (Missing)
8  (Missing)                              0x12dfd11e (Missing)
9  (Missing)                              0x12da927e (Missing)
10 system@framework@boot-framework.oat    0x74d6de0d (Missing)
11 (Missing)                              0x3fdec95c (Missing)
12 (Missing)                              0x12f39976 (Missing)
13 (Missing)                              0x12c2064e (Missing)
14 (Missing)                              0x70e43ada (Missing)
15 (Missing)                              0x12f43b8e (Missing)
16 libart.so                              0xebc85331 (Missing)
17 (Missing)                              0x70d268be (Missing)
18 system@framework@boot.oat              0x716279db (Missing)
19 (Missing)                              0x70837262 (Missing)
20 (Missing)                              0x70190306 (Missing)
21 (Missing)                              0x2cb6ab0c (Missing)
22 (Missing)                              0x70d58d82 (Missing)
23 (Missing)                              0x2cb6ab0c (Missing)
24 (Missing)                              0x2cb6ab0c (Missing)
25 (Missing)                              0x70c63cee (Missing)
26 (Missing)                              0x12c2064e (Missing)
27 (Missing)                              0x70e43ada (Missing)
28 (Missing)                              0x12f43c1e (Missing)
29 libart.so                              0xebca3526 (Missing)
30 (Missing)                              0x3fdec95c (Missing)
31 (Missing)                              0x70e43ada (Missing)
32 (Missing)                              0x70e43ada (Missing)
33 (Missing)                              0x12f39976 (Missing)
34 (Missing)                              0x12f43b8e (Missing)
35 libart.so                              0xebc85331 (Missing)
36 (Missing)                              0x70d268e2 (Missing)
37 (Missing)                              0x3fdec95c (Missing)
38 libutils.so                            0xee283ced (Missing)
39 (Missing)                              0x70abe4f6 (Missing)
40 (Missing)                              0x70aadb2e (Missing)
41 libandroid_runtime.so                  0xecdb23ff (Missing)
42 (Missing)                              0x70abe4f6 (Missing)
43 (Missing)                              0x12c2fa8e (Missing)
44 system@framework@boot-framework.oat    0x749d1865 (Missing)
45 (Missing)                              0x12c2fa8e (Missing)
46 system@framework@boot-framework.oat    0x741f0347 (Missing)
47 (Missing)                              0x70d3b9ca (Missing)
48 (Missing)                              0x12c2fa8e (Missing)
49 (Missing)                              0x12c2fa8e (Missing)
50 (Missing)                              0x70abe4f6 (Missing)
51 (Missing)                              0x70aadb2e (Missing)

Answer 13 · 2019-04-16T16:06:07.000Z

Having the same issue with Samsung Galaxy S7, on Android 7

ASSERT|04-17 00:30:16.272|18763|18813||libc|Fatal signal 11 (SIGSEGV), code 1, fault addr 0xbbadbeef in tid 18813 (mqt_js)
ASSERT|04-17 00:30:16.402|18920|18920||DEBUG|Build fingerprint: 'samsung/heroltexx/herolte:7.0/NRD90M/G930FXXS1DQHF:user/release-keys'
ASSERT|04-17 00:30:16.402|18920|18920||DEBUG|*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
ASSERT|04-17 00:30:16.405|18920|18920||DEBUG|ABI: 'arm64'
ASSERT|04-17 00:30:16.405|18920|18920||DEBUG|Revision: '8'
ASSERT|04-17 00:30:16.406|18920|18920||DEBUG|pid: 18763, tid: 18813, name: mqt_js  >>> com.profibackoffice.reactnative <<<
ASSERT|04-17 00:30:16.406|18920|18920||DEBUG|signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xbbadbeef
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x16  00000070110b1acc  x17  000000700bc121a8  x18  0000000021ecfc88  x19  000000700fed7e80
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x20  00000070108cf560  x21  0000006ffd4c8070  x22  000000700bc00000  x23  0000006ff9616ca0
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x28  ffff000000000002  x29  00000070108cf560  x30  0000007011408484
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x24  0000000000000007  x25  0000000000000000  x26  0000000000000000  x27  ffff000000000000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x8   00000000bbadbeef  x9   00000070114b19d0  x10  0000000000000000  x11  0000006ffc4f0000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x0   00000070108cf3c8  x1   00000070108cf3c8  x2   0000000000000000  x3   00000000000000a8
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    sp   00000070108cf400  pc   000000701140848c  pstate 00000000a0000000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x4   000000700bfaee80  x5   0000006ff62a4980  x6   0000006ffa6a6820  x7   0000000000000000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x12  0000000000000000  x13  000000700b617c00  x14  0000000000000002  x15  00000000bd36143d
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG|backtrace:
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG|    #03 pc 00000000001afe80  <anonymous:000000700bdff000>
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG|    #02 pc 0000000000489f2c  /data/app/com.profibackoffice.reactnative-1/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG|    #01 pc 00000000000be650  /data/app/com.profibackoffice.reactnative-1/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i+24)
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG|    #00 pc 00000000007e048c  /data/app/com.profibackoffice.reactnative-1/lib/arm64/libjsc.so (WTFCrash+16)

Answer 14 · 2019-04-16T16:10:38.000Z

~~Adding this to your android/app/build.gradle ~~may fix it~~ (It didn't):~~

packagingOptions {
      pickFirst '**/libjsc.so'
      pickFirst '**/libc++_shared.so'
}

~~See react-native-community/jsc-android-buildscripts#95~~

Answer 15 · 2019-04-16T16:26:28.000Z

Thank you for trying to help but the solution has not helped us.

…

16 апр. 2019 г., в 19:12, Andrew Jack ***@***.***> написал(а): Adding this to your android/app/build.gradle may fix it: packagingOptions { pickFirst '**/libjsc.so' pickFirst '**/libc++_shared.so' } See react-native-community/jsc-android-buildscripts#95 <react-native-community/jsc-android-buildscripts#95> Testing this now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24261 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEO_1BMzddSncn2DtQeDcx_y1KIz0ZSGks5vhfaJgaJpZM4cX_xB>.

Answer 16 · 2019-04-16T21:16:09.000Z

Adding this to your android/app/build.gradle may fix it:
packagingOptions {
      pickFirst '**/libjsc.so'
      pickFirst '**/libc++_shared.so'
}
See react-native-community/jsc-android-buildscripts#95

I'm testing this now.

@AndrewJack was it working for you?

Answer 17 · 2019-04-17T03:25:30.000Z

Adding this to your android/app/build.gradle may fix it:
packagingOptions {
      pickFirst '**/libjsc.so'
      pickFirst '**/libc++_shared.so'
}
See react-native-community/jsc-android-buildscripts#95

I'm testing this now.

Sadly we already had those in there.

We have pulled our 64-bit builds from the Play Store. This may not be related at all to the crash in the 64bit build, but Galaxy S7 devices running the armeabi-v7a build are now crashing a lot as per the below. Immediately upon startup.

Really wondering what is so different about the S7 compared to other devices.

Version Code: 10000036
Version Name: 2.3.4
Android: 8.0.0
Android Build: R16NW
Manufacturer: samsung
Model: SM-G930F
Date: undefined

com.facebook.react.bridge.UnexpectedNativeTypeException: TypeError: expected dynamic type `double', but had type `null'
  at com.facebook.react.bridge.ReadableNativeMap.getIntNative
  at com.facebook.react.bridge.ReadableNativeMap.getInt
  at com.facebook.react.g.a.a
  at com.facebook.react.modules.core.ExceptionsManagerModule.reportSoftException
  at java.lang.reflect.Method.invoke(Method.java:-2)
  at com.facebook.react.bridge.JavaMethodWrapper.invoke
  at com.facebook.react.bridge.JavaModuleWrapper.invoke
  at com.facebook.react.bridge.queue.NativeRunnable.run
  at android.os.Handler.handleCallback(Handler.java:789)
  at android.os.Handler.dispatchMessage(Handler.java:98)
  at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage
  at android.os.Looper.loop(Looper.java:164)
  at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run
  at java.lang.Thread.run(Thread.java:764)

Answer 18 · 2019-04-17T07:13:12.000Z

@taschik It didn't work, I thought correcting the jsc-android-buildscripts config might work.

Answer 19 · 2019-04-18T12:51:44.000Z

I'm getting the same exception and it can't be caught by uncaught exception handler. In my Android app I've tried this code:

Thread.setDefaultUncaughtExceptionHandler(...);

with handler, which only writes exception name to console and then returns control to default handler, but that code hadn't been executed before the app crash.

I was trying to investigate, why Crashlytics doesn't log this exceptions. Maybe that is the reason... I remember, that once or twice I've seen native crashes in my fabric console, so crashlytics is able to log native crashes, but somehow not in this case.

Answer 20 · 2019-04-18T13:12:17.000Z

@SpertsyanKM The crash occurs at the ndk level. You won't see the crash in the firebase console, unless you add the Crashlytics NDK library. https://docs.fabric.io/android/crashlytics/ndk.html

As you've found the Thread.setDefaultUncaughtExceptionHandler will only catch Java exceptions.

Answer 21 · 2019-04-19T18:43:42.000Z

I upgraded to RN 0.59.5 today and the crash still happens. This issue is not yet fixed.

Answer 22 · 2019-04-22T03:47:26.000Z

Hi, everyone, I hava same issue in 0.59.5, remove android:screenOrientation="portrait" in AndroidManifest.xml. It works for me.

Answer 23 · 2019-04-22T04:58:58.000Z

@Jeijie I already did not have that in there, but it crashed anyway.

Answer 24 · 2019-04-23T02:02:21.000Z

same issue on REDMI NOTE 4X Android 7.0 and huawei HRY AL00A Android 9

AutomaticThread
SIGSEGV(SEGV_MAPERR)
1 #00 pc 000000000042c064 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
2 #01 pc 0000000000429638 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
3 #02 pc 0000000000429d28 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
4 #03 pc 000000000041664c /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
5 #04 pc 00000000007ea4cc /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
6 #05 pc 00000000007eabcc /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
7 #06 pc 00000000007e0fec /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
8 #07 pc 00000000007ee4fc /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
9 #08 pc 00000000007ffdb8 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
10 #09 pc 0000000000083550 /system/lib64/libc.so (__pthread_start(void*)+36) [arm64-v8a]
11 #10 pc 00000000000241a0 /system/lib64/libc.so (__start_thread+68) [arm64-v8a]
12 java:
13 [Failed to get Java stack]

Answer 25 · 2019-04-24T09:02:05.000Z

Same problem on Galaxy S7 Edge / Android 7.0 and with three different versions of React-Native : 0.58.4, 0.58.5 and 0.59.5.
The crash has not been detected on others Android devices.

Only solution to avoid this issue currently is to build the app only on 32 bits. But the issue needs to be fixed for the first August because Play Store will not accept anymore only 32 bits apps.

Answer 26 · 2019-04-24T10:59:10.000Z

Experiencing the same, confined to Galaxy S7 with Android <= 7.0 (not 8.0). Happens since we enabled 64 bit support.

Answer 27 · 2019-04-24T22:44:12.000Z

As of our gradle default config we do not even support 64bit and the crashes happen nevertheless.

defaultConfig {
        applicationId _applicationId
        minSdkVersion 16
        targetSdkVersion 27 
        versionCode _versionCode
        versionName _versionName
        ndk {
            abiFilters "armeabi-v7a", "x86"
        }

        packagingOptions {
            exclude "lib/arm64-v8a/libgnustl_shared.so"
        }
        renderscriptTargetApi 27
        renderscriptSupportModeEnabled true
        vectorDrawables.useSupportLibrary = true /
        multiDexEnabled true 
    }```

Answer 28 · 2019-04-25T03:26:46.000Z

One more here, I've noticed that the issue happens with some Mediatek devices as well
Alcatel A5 (ELSA6)
Alcatel 1x / TCL L9 (U5A_PLUS_4G)
An some other devices with MediaTek SoCs with x64 support

Answer 29 · 2019-04-25T09:55:06.000Z

Hi. We've found that:

~~The fix to remove 64-bit support does work~~ This only fixed the issue for some of our users
~~We have had users fix this problem themselves by restarting their phone (no need to switch to 32-bit app)~~ They did not have the same issue.

Answer 30 · 2019-04-26T14:11:13.000Z

I can confirm that removing the 64bit support reduced the crash reports by ~90%
It is happening with some devices still. But the current "fix" is the best I can do right now

Answer 31 · 2019-04-28T23:34:33.000Z

I'm getting crashes on OnePlus 3 as well, but removing 64bit support doesn't help. I'm getting crashes with a clean react-native init project (also on emulators when opening app's APK).

Answer 32 · 2019-05-04T20:57:56.000Z

same problem s7 edge android 7.0 crashing in production with bundle split ,other seem to be ok
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
backtrace:
#00 pc 000000000009e144
#1 pc 00000000000a4a70

Answer 33 · 2019-05-06T21:44:38.000Z

This issue is already identified on the webkit repo. I have commented there when I discovered this issue months ago: WebPlatformForEmbedded/WPEWebKit#327 (comment)

It would be great to coordinate the efforts.

Note: at Youi we use RN in a non-standard way. We build our own 64-bit JSC, so we got this issue far earlier, prior to 0.58.

Answer 34 · 2019-05-07T09:40:19.000Z

The common factors seem to be Android 6.0 or 7.0 (Level 23 & 24) and ARM 64 devices.
The most common device with this combination is the S7. Upgrading an S7 to Android 8 fixes the issue.

I have reproduced the crash in an Android ARM 64 bit emulator, but the Android ARM emulator images are too unstable & buggy to work with. I also have an S7 to debug, which I'm attempting to downgrade to Android 7, though Samsung hasn't made this easy.

@kmagiera & @Kudo you recently released a new version of JSC. Are you expecting this release to fix this issue? Would aligning NDK versions help? react-native-community/jsc-android-buildscripts#95

Answer 35 · 2019-05-07T15:22:31.000Z

@AndrewJack The new release just for WebKit security patches & removing libc++_shared.so for #24672. I don't think these will fix the crash issues.

AFAIK, there are various JSC crash types.
Some are from operationLinkDirectCall as this issue reported and some are NPE as react-native-community/jsc-android-buildscripts#84.
Most of them are related to JIT.
JIT crash path is hard to reproduce in-house and hard to troubleshoot as well.
I have some potential fixes but not quite sure if those will truly solve the crash issue.

One of fixes is to disable DFG_JIT.
There is also a fix from upstream related operationLinkDirectCall
Newer JSC (WebKitGTK 2.24) includes a lot of JIT changes. Worth to try if upgrade helps.

IMO, if in-house reproduce is not possible, an alternative is to deliver experimented build.

My plan is to make upgrade JSC easier, simply yarn add jsc-android@experiment. This should happen at RN 0.60.
With this mechanism, at least we could be a step ahead to fix crash issues.

On the other hand, it would help if there are reliable reproduce code & environment.
For example, there is a repo from react-native-navigation. It helps much.
react-native-community/jsc-android-buildscripts#84 (comment)

Answer 36 · 2019-05-07T17:53:02.000Z

The crash happens also on Pixel 2 with Android 9, if that helps.
Is there any way to get crash logs when running APK? I'll be happy to help to get more information on these crashes, but I don't know much about Android development.

Answer 37 · 2019-05-07T20:19:00.000Z

@quietbits, most of the logs related to these issues are not super helpful, but to get it out:

Look for when the crash occurs using adb logcat—it'll look something like this (not exactly, since I just extracted this from the top of the log, but it shows an exerpt which is why I'm pointing it out):

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/heroqltetmo/heroqltetmo:8.0.0/R16NW/G930TUVU4CRI2:user/release-keys'
Revision: '14'
ABI: 'arm'
pid: 32435, tid: 32482, name: mqt_js  >>> com.YOURAPP <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xcd
Cause: null pointer dereference

It'll also usually say that the log is written to a "tombstone."

To get the tombstone off, use adb bugreport ./MySuperSpecialBugReport with the latter part obviously being the path you want it in.

It'll get it off as a zip, and you can unzip it, navigate (on most devices) to: ./MySuperSpecialBugReport/FS/data/tombstones and then you can open up the tombstone with your text editor.

Again, just given the nature of these crashes, they're not super informative. At least with ours, they're usually with mqt_js, and at a low pointer address. They also still occur (though less and less weirdly/unpredictably) with 32-bit only apks.

===

@Kudo—definitely looking forward to being able to try out different JSCs more easily and see what it does. This has been a real pain point so far in upgrading to 0.59 with super non-deterministic and unpredictable crashes (that also only occur on certain devices... sometimes).

Answer 38 · 2019-05-08T16:09:50.000Z

To get the symbolicated backtrace, I used to combine adb logcat and ndk-stack
For example, targeting RN 059 stock JSC (which is jsc-android@236355.0.0) and arm64-v8a ABI.

wget https://registry.npmjs.org/jsc-android/-/jsc-android-236355.0.0.tgz
tar xf jsc-android-236355.0.0.tgz
unzip package/dist/org/webkit/android-jsc/r236355/android-jsc-r236355.aar
adb logcat | ndk-stack -sym jni/arm64-v8a/libjsc.so

Answer 39 · 2019-05-10T10:41:36.000Z

Any update on this issue?

Answer 40 · 2019-05-16T08:32:12.000Z

Removing 64 bit is not a solution as per Google Play 64 bit support policy. It could potentially affect apps going live after 1 August 2019. We would like to have proper solution for this issue. @hramos any update on this ? Please draw some attention.

Answer 41 · 2019-05-16T15:15:50.000Z

Hi, everyone, I hava same issue in 0.59.8,
We would like to have proper solution for this issue.

Answer 42 · 2019-05-16T16:28:23.000Z

Hi,
I am helping with the JSC crash issue and also a collaborator of jsc-android-buildscripts.
RN 0.59 JSC is in fact from jsc-android-buildscripts.

To troubleshoot the crash issue, we need the crash backtrace.
Hopefully, please follow the steps to below get backtrace and post here.
I could then follow up to find potential solutions.

Install ndk-build and execute commands:

wget https://registry.npmjs.org/jsc-android/-/jsc-android-236355.0.0.tgz
tar xf jsc-android-236355.0.0.tgz
unzip package/dist/org/webkit/android-jsc/r236355/android-jsc-r236355.aar
adb logcat -c
adb logcat | ndk-stack -sym jni/arm64-v8a/libjsc.so

It seems a lot of crash comes from Samsung S7. Unfortunately, I have no S7 at hand.
Hopefully to get some useful information to go further troubleshooting.

Answer 43 · 2019-05-16T21:55:12.000Z

@marlonchalegre

Answer 44 · 2019-05-16T21:55:35.000Z

@Kudo This is the log I got running those commands on a fresh project on RN 0.59.8
I tried building debug and release builds and compiling the jsc myself by the logs looked the same in each case.

********** Crash dump: **********
Build fingerprint: ‘samsung/heroltexx/herolte:7.0/NRD90M/G930FXXU1DQEL:user/release-keys’
#00 0x00000000007e048c /data/app/com.testproj-2/lib/arm64/libjsc.so (WTFCrash+16)
                                                                    WTFCrash
                                                                    ??:0:0
#01 0x00000000000be650 /data/app/com.testproj-2/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i+24)
                                                                    WTFCrashWithInfo(int, char const*, char const*, int)
                                                                    ??:0:0
#02 0x0000000000489f2c /data/app/com.testproj-2/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
                                                                    operationLinkDirectCall
                                                                    ??:0:0
#03 0x00000000001710f0 <anonymous:00000072adbff000>
Crash dump is completed

I have a S7 at hand and would be happy to try running anything else to try and figure this out.

Answer 45 · 2019-05-17T05:21:59.000Z

My suggestion is to recompile the JSC with JIT disabled. It’s possible the security mechanisms in the OS interfere with the JIT’s
operations in some unpredictable way.

Answer 46 · 2019-05-17T11:36:20.000Z

I've reproduced the same crash logs as @MalcolmScruggs. On a S7 - Android 7.1.2 - LineageOS 14.1.

On RN 0.59.8 & the latest version of the master branch.

No changes required to reproduce crash. The default RN template trigger a crash after a bit of tapping on the screen.

Repo here - https://github.com/AndrewJack/jsc_crash/tree/rn_master_branch
Crash logs are in the README.md

Next steps: build own version of JSC with JIT disabled

If anyone has a S7 on a newer version of Android and they want to downgrade. This is what I did:

Download this software:

https://twrp.me/samsung/samsunggalaxys7.html
https://www.los-legacy.de/ v14.1 - herolte
https://opengapps.org/

Install TWRP recovery (using odin [requires windows] or other method)
Boot into recovery
mount storage
copy LineageOS rom & gapps package
install flash LineageOS and gapps images
reboot.

Answer 47 · 2019-05-17T12:08:35.000Z

With latest react native master and using no_dfg_jit or no-jit from @Kudo's fork I cannot reproduce the crash.

https://github.com/AndrewJack/jsc_crash/tree/no_dfg_jit
https://github.com/AndrewJack/jsc_crash/tree/no_jit

Answer 48 · 2019-05-17T13:36:56.000Z

@AndrewJack Amazing, you found my experimented builds so quick.
Thanks for your feedback and good to know these versions fixed the crash for you.

Answer 49 · 2019-05-17T13:41:43.000Z

Dears,

I had two experimented JSC versions, please try if these could fix crashes for you.
A brief steps here:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

One experimented version is to disable one kind of JIT.
And the other one disable JIT totally from @matthargett recommended.
If the two versions will fix crash for you, please also feedback to us the overall performance & TTI as mentions in my gist.

Answer 50 · 2019-05-17T13:51:40.000Z

@Kudo Thanks for those! What do you know about concurrent GC in those builds? I saw mentioned somewhere that was another difference compared to the 32 bit version, but of course I cannot find that comment anymore. May be another thing worth playing with incase crashes do persist.

Answer 51 · 2019-05-17T15:13:44.000Z

@wbercx Do you mean concurrent GC or concurrent JS (concurrent JIT)?
By default, concurrent GC is only enabled for arm64 and x64.
Concurrent GC may not relate to the crash issue. It is likely about heap management and not JIT related.

Concurrent JS is disabled for my both builds.
(By default, it will only enabled for ENABLE(DFG_JIT) && USE(JSVALUE64))

BTW, JIT in JavaScriptCore is complicated and I am not an expert for this.
Feel free to point out if I was wrong.

Answer 52 · 2019-05-17T17:16:02.000Z

@Kudo I tried out your no-jit and no-dfg-jit experimental JSC versions and was unable to reproduce the crash. This seems to be in line with what @AndrewJack reported.

I was trying this on a basic project so I can't comment on any performance impact.

Answer 53 · 2019-05-17T23:50:51.000Z

I have some more info, I'm seeing this crash too on:
Samsung Galaxy S7 (herolte), Android 7.0
Oppo F7 (CPH1819), Android 8.1

Answer 54 · 2019-05-17T23:58:20.000Z

Also happening on 0.58.5. Galaxy S7. Android 6.0. Setting it to 32 bit build is also not working.

The crash is still happening here too after reverting to 32 bit

Answer 55 · 2019-05-20T11:03:55.000Z

@MalcolmScruggs Nice to hear both the experimented versions fix the crash for you.
I am thinking to disable DFG_JIT, at least the JIT option is aligned with old JSC.

Answer 56 · 2019-05-20T22:15:55.000Z

@Kudo Are planning on targeting your fix of disabling DFG_JIT only to affected devices / CPUs?

Answer 57 · 2019-05-21T09:31:42.000Z

Did someone tried with last version of React Native (0.59.8) which is fixing some crashes (mentioned in release note) ?
https://github.com/facebook/react-native/releases

Answer 58 · 2019-05-21T19:16:00.000Z

Did someone tried with last version of React Native (0.59.8) which is fixing some crashes (mentioned in release note) ?
https://github.com/facebook/react-native/releases

In my case I was using 0.59.8, I've since then reverted to 0.57.8 since nothing else seemed to work. This bug is particularly bad because it causes the app to crash immediately upon opening. My app took quite a haircut in the reviews.

These devices have a signal 11 crash but it just shows a memory location.

General Mobile GM8 Go - Android 8.1
Motorola Moto E - Android 7.1
Samsung Galaxy A6+ - Android 8.0
Samsung Galaxy Grand Prime Pro - Android 8.0
Samsung Galaxy Tab S2 - Android 8.0
Samsung Galaxy J5 Prime - Android 8.0
Samsung Galaxy J6 - Android 8.0
Samsung Galaxy J7 Max - Android 8.1

These devices seem to show up with an error that looks like ==/lib/arm64/libjsc.so. I don't know enough about the inner workings to know what that means, but hopefully it helps.

Huawei Y9 - Android 8.1
Oppo RMX1811 - Android 8.1
Oppo R15 - Android 8.1
Motorola Moto X - Android 9.0
Nokia 3 - Android 8.1
Samsung Galaxy Note9 - Android 9.0
Samsung Galaxy S9 - Android 9.0
Xaomi Redmi Note 5 Pro - Android 8.1

Answer 59 · 2019-05-22T08:40:18.000Z

I can add some devices to the list of @harryt2.

Signal 11 crash with only a memory location:

Samsung Galaxy Note 9 - Android 9.0
Huawei Honor 8X - Android 9.0
Samsung Galaxy A7 (2018) - Android 9.0
Samsung Galaxy S9 - Android 9.0
Samsung Galaxy A6+ - Android 9.0
Nokia Nokia 8 - Android 9.0
Huawei Huawei P30 lite - Android 9.0
Samsung Galaxy Note8 - Android 9.0
Samsung Galaxy A9 - Android 8.0
Samsung Galaxy S7 - Android 8.0
...
list continues with ~65 different devices and Android version between 7.0 and 9.0.

The error does not always occur on this devices. But it is a real concern, since the crash rate of my application reported in google play changed from 0.16% to 1.02% after the update from 0.57.8 to 0.59.5.

0.57.8:

0.59.5:

I'm not an expert in Android development, nor do I understand where this crash is coming from. I can provide some more data if it helps.

Answer 60 · 2019-05-22T14:45:07.000Z

@ntorion on our project we still see these crashes on Samsung s7 with react-native 0.59.8 i'm afraid.

Answer 61 · 2019-05-22T22:44:33.000Z

Any solution for this at this moment?
I've tested in two different galaxy note 9, every phone crashes immediately

{"dependencies": {
    "axios": "^0.18.0",
    "prop-types": "^15.7.2",
    "react": "16.8.3",
    "react-native": "0.59.8",
    "react-native-gesture-handler": "^1.2.1",
    "react-native-iphone-x-helper": "^1.2.0",
    "react-native-linear-gradient": "^2.5.4",
    "react-native-vector-icons": "^6.4.2",
    "react-navigation": "^3.11.0",
    "react-redux": "^7.0.3",
    "reactotron-react-native": "^3.5.2",
    "reactotron-redux": "^3.1.0",
    "reactotron-redux-saga": "^4.2.2",
    "realm": "^2.27.0",
    "redux": "^4.0.1",
    "redux-saga": "^1.0.2",
    "reduxsauce": "^1.1.0",
    "seamless-immutable": "^7.1.4",
    "styled-components": "^4.2.0"
  },
  "devDependencies": {
    "@babel/core": "^7.4.5",
    "@babel/runtime": "^7.4.5",
    "babel-eslint": "^10.0.1",
    "babel-jest": "^24.8.0",
    "babel-plugin-root-import": "^6.2.0",
    "eslint": "^5.16.0",
    "eslint-config-airbnb": "^17.1.0",
    "eslint-import-resolver-babel-plugin-root-import": "^1.1.1",
    "eslint-plugin-import": "^2.17.2",
    "eslint-plugin-jsx-a11y": "^6.2.1",
    "eslint-plugin-react": "^7.13.0",
    "eslint-plugin-react-native": "^3.7.0",
    "jest": "^24.8.0",
    "metro-react-native-babel-preset": "^0.54.1",
    "react-test-renderer": "16.8.3"
  }}

Answer 62 · 2019-05-23T08:38:40.000Z

@dudusotero use @Kudo instruction https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Answer 63 · 2019-05-23T09:14:07.000Z

@matpaul @Kudo i can confirm that this experimental build of js core seems to fix the issue for us as well (tested on Samsung s7).

Answer 64 · 2019-05-23T16:50:52.000Z

My crashes related to this this trace went away on Android when I downgraded to 0.58.6. Was planning on having to downgrade to 57.6, but 58.6 seems to have fixed this for me (although there are some other Android issues I had to mitigate, where I have to manually build for release)

Answer 65 · 2019-05-24T11:44:50.000Z

@Kudo

Dears,

I had two experimented JSC versions, please try if these could fix crashes for you.
A brief steps here:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

One experimented version is to disable one kind of JIT.
And the other one disable JIT totally from @matthargett recommended.
If the two versions will fix crash for you, please also feedback to us the overall performance & TTI as mentions in my gist.

@Kudo I had two observations here, as also mentioned in your gist

App hangs with @kudo-ci/jsc-android@241213-no-dfg-jit dependency, when using one of our production app for few minutes.
App is working fine with @kudo-ci/jsc-android@241213-no-jit dependency as of now and TTI remains the same/unnoticeable with respect to previous builds.

Kudo, will your pull request be sufficient enough to fix this, as I noticed the hanging of the app when tested against no_dfg_jit

Answer 66 · 2019-05-28T02:44:57.000Z

Some more update here:
I really doubt if the native crash happens easily on S7 edge, there should be other applications faced such problems.
Gotcha!
Google Play Service with Text API had this problems but no OSS fix
Mono found a crash issue on S7 Exynos bit.LITTLE arch and here is the fix.

JavaScriptCore did use __clear_cache in ARM64Assembler.
I will have another experimented build to patch __clear_cache later this week.

Answer 67 · 2019-05-28T15:30:46.000Z

The experimented builds that fixed __clear_cache have ready.

The steps are same as before but only to use different npm dependency.

yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-dfg' and confirmed adb logcat with version 241213.8000.0 (ref source code here)
yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg' and confirmed adb logcat with version 241213.9000.1 (ref source code here)

I am sorry I cannot verify the crash issue again but only to verify basic functionalities.
Please help to test the two experiment JSC if possible.
Thank you all so much and wish us good luck this time.

cc @AndrewJack @MalcolmScruggs @tijs @ishantsagar @timhatch

Answer 68 · 2019-05-28T21:11:58.000Z

@Kudo I've now had feedback on test builds using both @kudo-ci/jsc-android@241213-fix-clear-cache-dfg and @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg.
Both test builds appear to be crash-free so far on the Samsung Galaxy S7 Edge / Android 7.0 (up to now the problem combination)

Answer 69 · 2019-05-28T23:14:20.000Z

@Kudo I tried out both @kudo-ci/jsc-android@241213-fix-clear-cache-dfg and @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg on a basic project running React-Native 0.59.8 and on both versions the crash is not happening. I tested on a Samsung Galaxy S7 on android 7.0:

[ro.product.board]: [universal8890]
[ro.product.brand]: [samsung]
[ro.product.cpu.abi]: [arm64-v8a]
[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: [arm64-v8a]
[ro.product.device]: [herolte]
[ro.product.first_api_level]: [23]
[ro.product.locale]: [en-GB]
[ro.product.manufacturer]: [samsung]
[ro.product.model]: [SM-G930F]
[ro.product.name]: [heroltexx]

Answer 70 · 2019-05-29T16:11:11.000Z

@Kudo I've tried the latest @kudo-ci/jsc-android@241213-fix-clear-cache-dfg but I have encountered a crash on a Samsung Galaxy S5 (SM-G900F), similar to the one we had with the JSC in React Native 0.59.8

The version without JIT was working perfectly (@kudo-ci/jsc-android@241213-no-jit) and haven't encountered any crashes on that one regardless of how much I've pushed the app to the limits. So I think we'll stick with that one for now.

We are using ReactRootViews in a viewpager, so we create and destroy react-native instances quite often, and that seems to be triggering this crash. That's probably why we are encountering this issue more often than most. We are re-visiting the viewpager approach at the moment, but in the meanwhile, I'm hoping this crash log can be helpful. (it's for version 241213.8000.0, react-native 0.59.8)

A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x66 in tid 16184 (mqt_js)
D/InputReader: Input event: value=1
I/InputReader: Touch event's action is 0x0 (deviceType=0) [pCnt=1, s=0.1239 ] when=8467503214000
I/InputDispatcher: Delivering touch to (1173): action: 0x4, toolType: 1
I/InputDispatcher: Delivering touch to (16117): action: 0x0, toolType: 1
I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG: Build fingerprint: 'samsung/kltexx/klte:5.0/LRX21T/G900FXXU1BOH4:user/release-keys'
I/DEBUG: Revision: '14'
I/DEBUG: ABI: 'arm'
I/DEBUG: pid: 16117, tid: 16184, name: mqt_js  >>> uk.co.thetimes.debug <<<
I/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x66
I/DEBUG:     r0 00000036  r1 8cc43b20  r2 8e558040  r3 fffffffb
I/DEBUG:     r4 00000000  r5 91800000  r6 8c752df0  r7 92efea88
I/DEBUG:     r8 fffffffb  r9 8cce0000  sl 91a08821  fp fffffffc
I/DEBUG:     ip 8c752df0  sp 92efe8e0  lr 91d970a9  pc 91ea6502  cpsr 600b0030
I/DEBUG: backtrace:
I/DEBUG:     #00 pc 004a7502  <unknown>
I/DEBUG:     #01 pc 003980a7  <unknown>

Answer 71 · 2019-05-29T17:06:16.000Z

Sadly we already had those in there.

We have pulled our 64-bit builds from the Play Store. This may not be related at all to the crash in the 64bit build, but Galaxy S7 devices running the armeabi-v7a build are now crashing a lot as per the below. Immediately upon startup.

Really wondering what is so different about the S7 compared to other devices.

Version Code: 10000036
Version Name: 2.3.4
Android: 8.0.0
Android Build: R16NW
Manufacturer: samsung
Model: SM-G930F
Date: undefined

com.facebook.react.bridge.UnexpectedNativeTypeException: TypeError: expected dynamic type `double', but had type `null'
  at com.facebook.react.bridge.ReadableNativeMap.getIntNative
  at com.facebook.react.bridge.ReadableNativeMap.getInt
  at com.facebook.react.g.a.a
  at com.facebook.react.modules.core.ExceptionsManagerModule.reportSoftException
  at java.lang.reflect.Method.invoke(Method.java:-2)
  at com.facebook.react.bridge.JavaMethodWrapper.invoke
  at com.facebook.react.bridge.JavaModuleWrapper.invoke
  at com.facebook.react.bridge.queue.NativeRunnable.run
  at android.os.Handler.handleCallback(Handler.java:789)
  at android.os.Handler.dispatchMessage(Handler.java:98)
  at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage
  at android.os.Looper.loop(Looper.java:164)
  at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run
  at java.lang.Thread.run(Thread.java:764)

We have seen this internally and noticed that some of our styling properties were conditionally returning null. Removing that and only conditionally adding the style property fixed a similar exception -- there might be something going on with a native module type for yours?

Answer 72 · 2019-05-29T18:02:53.000Z

@tuncaulubilge Thanks for the information.
Just to double confirm that Samsung S5 (SM-G900F) is arm (not arm64) architecture, right?
You may verify by adb shell getprop ro.product.cpu.abi
From your crash log, it seems to be arm.

If so, I am assuming the root cause should be yet another story than here.
Did you ever test the no-dfg-jit version, i.e. @kudo-ci/jsc-android@241213-no-dfg-jit or @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg?
These two versions should be same on arm32, you could just test either one.

Answer 73 · 2019-05-29T19:11:28.000Z

@Kudo UPDATE

The backtrace reported back through the developer console for the original problem (repeatable crashes on application launch on [exclusively] Samsung S7 Edge + Android 7.0) looks like so:

 #00  pc 00000000007e048c  /data/app/org.ifsc.boulder14-1/lib/arm64/libjsc.so (WTFCrash+16)
 #01  pc 00000000000be650  /data/app/org.ifsc.boulder14-1/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i+24)
 #02  pc 0000000000489f2c  /data/app/org.ifsc.boulder14-1/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
 #03  pc 00000000002149a8  <unknown>

The original problem appears to be fixed by each of the following builds:
@kudo-ci/jsc-android@241213-no-jit
@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg
@kudo-ci/jsc-android@241213-fix-clear-cache-dfg

I have however managed to stimulate another crash on two occasions for the last of these (@kudo-ci/jsc-android@241213-fix-clear-cache-dfg) on a different device and with a different backtrace:

  #00  pc 00000000004886ac  /data/app/org.ifsc.boulder14-ECb5NhJUQgyp_UkWAZLdKg==/lib/arm64/libjsc.so (operationLinkDirectCall+176)
  #01  pc 000000000043ad90  <anonymous>

Although I've managed to crash the test app twice, each time with the same signature, the crash is not systematically repeatable and occurs during navigation between different screens in the test app and not on launch. As the relevant device is to hand, I've been able to pull a more complete trace from the device which reads as follow:

05-29 15:39:06.132  9361  9361 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1c
05-29 15:39:06.132  9361  9361 F DEBUG   : Cause: null pointer dereference
05-29 15:39:06.132  9361  9361 F DEBUG   :     x0  0000007363fc4900  x1  000000735b75a000  x2  0000000000000004  x3  0000000000000000
05-29 15:39:06.132  9361  9361 F DEBUG   :     x4  000000736470caa0  x5  e805b658e92d4328  x6  0000007368dfc8f0  x7  0000000000000000
05-29 15:39:06.132  9361  9361 F DEBUG   :     x8  0000000000000007  x9  0000000000000000  x10 0000007364d39d80  x11 0000000000000040
05-29 15:39:06.132  9361  9361 F DEBUG   :     x12 0000007364d39d80  x13 000000000000b324  x14 00000000ffdaeb75  x15 00000073609a09c0
05-29 15:39:06.132  9361  9361 F DEBUG   :     x16 000000736a1515fc  x17 00000073647121a8  x18 0000000000000002  x19 000000735b75a000
05-29 15:39:06.132  9361  9361 F DEBUG   :     x20 0000007368dfca10  x21 0000007363f0c070  x22 0000007364700000  x23 0000000000000004
05-29 15:39:06.132  9361  9361 F DEBUG   :     x24 0000000000000000  x25 0000000000000007  x26 0000000000000000  x27 ffff000000000000
05-29 15:39:06.132  9361  9361 F DEBUG   :     x28 ffff000000000002  x29 0000007368dfca10
05-29 15:39:06.132  9361  9361 F DEBUG   :     sp  0000007368dfc920  lr  000000736a1516ac  pc  000000736a1516ac
05-29 15:39:06.154  9361  9361 F DEBUG   : 
05-29 15:39:06.154  9361  9361 F DEBUG   : backtrace:
05-29 15:39:06.154  9361  9361 F DEBUG   :     #00 pc 00000000004886ac  /data/app/org.ifsc.boulder14-ECb5NhJUQgyp_UkWAZLdKg==/lib/arm64/libjsc.so (operationLinkDirectCall+176)
05-29 15:39:06.154  9361  9361 F DEBUG   :     #01 pc 000000000043ad90  <anonymous:00000073648ff000>

and

05-29 15:10:13.010  7853  7853 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1018
05-29 15:10:13.010  7853  7853 F DEBUG   :     x0  00000073642c6c40  x1  0000007359684500  x2  0000000000001000  x3  0000000000000000
05-29 15:10:13.010  7853  7853 F DEBUG   :     x4  00000073008a3030  x5  000000000000006d  x6  00000000ffffffff  x7  cb010063d1004021
05-29 15:10:13.010  7853  7853 F DEBUG   :     x8  0000000000000007  x9  0000000000000000  x10 00000073651159c0  x11 0000000000000040
05-29 15:10:13.010  7853  7853 F DEBUG   :     x12 00000073651159c0  x13 000000736a744558  x14 000000736249dc00  x15 000000736928a2e8
05-29 15:10:13.010  7853  7853 F DEBUG   :     x16 000000736a1575fc  x17 0000007364a121a8  x18 0000000000000045  x19 0000007359684500
05-29 15:10:13.010  7853  7853 F DEBUG   :     x20 000000736928a2a0  x21 0000007362fb7700  x22 0000007364a00000  x23 0000000000001000
05-29 15:10:13.010  7853  7853 F DEBUG   :     x24 0000000000000000  x25 0000000000000007  x26 0000000000000000  x27 ffff000000000000
05-29 15:10:13.010  7853  7853 F DEBUG   :     x28 ffff000000000002  x29 000000736928a2a0
05-29 15:10:13.010  7853  7853 F DEBUG   :     sp  000000736928a110  lr  000000736a1576ac  pc  000000736a1576ac
05-29 15:10:13.024  7853  7853 F DEBUG   : 
05-29 15:10:13.024  7853  7853 F DEBUG   : backtrace:
05-29 15:10:13.024  7853  7853 F DEBUG   :     #00 pc 00000000004886ac  /data/app/org.ifsc.boulder14-ECb5NhJUQgyp_UkWAZLdKg==/lib/arm64/libjsc.so (operationLinkDirectCall+176)
05-29 15:10:13.024  7853  7853 F DEBUG   :     #01 pc 00000000005169d8  <anonymous:0000007364bff000>

No idea if this helps, crash debugging and interpretation on Android is not something I've done before

Answer 74 · 2019-05-30T11:10:39.000Z

@Kudo Here are my findings:

The Samsung S5 is armeabi-v7a. I've tried all 4 alternatives you have provided, and the one without jit seems to be the only crash free one. Disabling dfg reduces the crash rate quite a lot but I could still crash it.

I'm also testing on a Pixel XL (arm64-v8a) and haven't encountered any crashes yet on kudo-ci/jsc-android@241213-fix-clear-cache-no-dfgbut the crash is hard to reproduce on a high end devices as the root cause seems to be low memory pressure.

To sum up:
@kudo-ci/jsc-android@241213-no-jit: This is crash free on both devices
@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg: This does crash on low end devices, couldn't reproduce on high end ones
@kudo-ci/jsc-android@241213-fix-clear-cache-dfg: This crashes more frequently than the other build on a low end device. (still better than the stock RN 59 jsc)
@kudo-ci/jsc-android@241213-no-dfg-jit: This crashed on low end devices as well, I haven't tested on a high end.

Even the build without jit is considerably faster than the stock JSCs, so we are planning to use @kudo-ci/jsc-android@241213-no-jit and we'll be testing it more to ensure it's production ready.

Thanks a lot for all the help by the way. Let me know if I could be of any help

Answer 75 · 2019-05-30T16:00:22.000Z

@timhatch @tuncaulubilge Thanks for your awesome systematically testing and feedback.
Right now I really have no idea to fix the problem.
Neither disable DFG nor fixing __clear_cache helps with that.
Moreover the crash happens on arm32 as well (and the root cause may be different than arm64)

In my personal opinion, I would like to disable JIT at all by default, at least to make sure we have a crash free JSC first.
BTW @tuncaulubilge how did you measure that @kudo-ci/jsc-android@241213-no-jit be faster than stock JSC?
Just curious since from the benchmark result, no-jit version acts a little slower.

Answer 76 · 2019-05-30T18:02:17.000Z

@Kudo Did you also measure app startup time and memory usage? I've always assumed that these two metrics would be better without JIT. Since most apps are UI heavy, I'm not sure JIT will be of much benefit in real world apps, so I would love to have JIT disabled if it improves startup and memory usage. I'm also curious whether JSC will have a smaller disk footprint without JIT.

Answer 77 · 2019-05-31T08:40:02.000Z

@Kudo
Fixing __clear_cache as you did in these test builds is definitely improving the situation, but either there is a side effect from the fix or a more complex interaction that isn't yet obvious. That said, I haven't been able to again crash the -fix-clear-cache-dfg test app. It may be that as @tuncaulubilge says, the behaviour depends upon memory pressure and/or other factors.

Disabling JIT completely appears to be the "crash free" option, I haven't noticed performance degradations with this option so it would be the "safe" choice.

Answer 78 · 2019-05-31T09:45:09.000Z

@Kudo to clarify, I've been comparing React-Native 0.58.6 (without any custom jsc installed) vs 0.59.8 with @kudo-ci/jsc-android@241213-no-jit.

I haven't done any measurements but the performance improvement is very noticable. I'd expect the no jit version to be a bit slower than the jsc@241213.0.0 as you mentioned, but that's ignorable in comparison. I'd suggest going with no-jit version as the default option as well, as the stability improvements heavily outweighs the minor performance improvement you'd get from jit.

Answer 79 · 2019-05-31T14:12:59.000Z

We are using Expo v32 to build our app and we are seeing this error across Android versions and devices.

Answer 80 · 2019-05-31T15:56:41.000Z

@tido64 TTI has no much differences. Binary size reduces about 1MB from no_dfg version. Memory reduces about 48%.
I've sent a PR to disable JIT totally and there is measurement result.
react-native-community/jsc-android-buildscripts#108

@timhatch Good to hear fixing __clear_cache helps a little.
I still doubt the root cause is from big.LITTLE, but I didn't find other JSC code to cause problems yet.
Both Samsung S5 and S7 are big.LITTLE and the two CPU set have different cache line size.
That maybe the reason why I was unable to reproduce crash on Samsung Note 5, that its two CPU set cache line size are both 64B.
Not sure if it is possible for OS scheduler and JSC to transition between big <-> LITTLE CPU at runtime.
If it is true, the problem may especially happens at that time.

@tuncaulubilge That's curious for me.
You could check my PR, the no-jit version is slower than stock RN058 JSC.
That's also what I felt during measurement.
Maybe the benchmarks are extreme cases and pretty not like a RN app used to be.
BTW, I did see the binary size & memory size reduces from no-jit version.
These two benefits and crash free are more reasonable to me.

Answer 81 · 2019-06-02T02:40:35.000Z

This code saves lifes

Answer 82 · 2019-06-02T15:00:52.000Z

@RomanovYurii When we removed 64 bit ndk filters "arm64-v8a", "x86_64" from ndk abiFilters in defaultConfig block of build.gradle by provide only 32 bit support. The crash has gone but as per Google 64 bit support mandate this needs to be fixed with 64 bit ndk support .

Answer 83 · 2019-06-03T06:07:21.000Z

@dishantwalia @Kudo disabled JIT works for me on 64 bit & not seeing any performance issues so far.

Answer 84 · 2019-06-03T09:15:41.000Z

This gist worked for me https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Answer 85 · 2019-06-04T13:56:32.000Z

Dears,

We've published the no-JIT JSC into jsc-android npm and I revised my previous gist to use jsc-android@next.
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Hopefully to fix all the crash problems.
If there aren't significant performance drop, we will propose the no-JIT version as @latest version officially and send a PR to have it builtin in newer RN.

Answer 86 · 2019-06-04T14:24:49.000Z

Dears,

We've published the no-JIT JSC into jsc-android npm and I revised my previous gist to use jsc-android@next.
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Hopefully to fix all the crash problems.
If there aren't significant performance drop, we will propose the no-JIT version as @latest version officially and send a PR to have it builtin in newer RN.

Thanks @Kudo disable-jit works for us like a charm !!!

Answer 87 · 2019-06-04T22:57:16.000Z

Thanks @Kudo for all the hard work! 241213.2.0 seems to have resolved the crashes for us. Unfortunately, the performance impact is pretty significant. On low-end devices on some of our busier screens we've seen js fps decrease by 20-30%.

Answer 88 · 2019-06-05T08:08:48.000Z

I can also confirm the crashes are gone but we are also seeing quite poor performance in lower end devices. Gotta say it's extremely disappointing considering we've been waiting to upgrade to RN58/RN59 for the more modern JSC.

Answer 89 · 2019-06-05T15:08:53.000Z

@Kudo worst case scenario the jit should only be disabled for the 64bit version, only 64bit capable devices are crashing

Answer 90 · 2019-06-05T15:11:35.000Z

@yenda if that build does become the fix it would be nice to have that option yes. Not sure how hard it would be. Hopefully that would not mean shipping two versions of the JSC

Answer 91 · 2019-06-05T19:15:32.000Z

@benoitdion @ItsNoHax Can you list the specific devices you observed poor performance on? Thanks!

Answer 92 · 2019-06-05T19:49:10.000Z

Tested on a Nexus 5 and Samsung Tab E among others.

Answer 93 · 2019-06-08T11:56:15.000Z

For any Googlers who are upgrading their RN project to 59.x, make sure that in android/app/build.gradle -> android { defaultConfig { versionName } } is not getting matched with your react-native-code-push specified version.

I struggled around three days for the same issue and later found out that my upgraded React Native project at v59.3 was getting updated by code-push which has React Native v54.7

This must not be the case for 90% of the people. But for some like me, it can save time.

After that thanks to @Kudo. Fixed the crash issues.

Answer 94 · 2019-06-13T11:37:13.000Z

Huawei Honor 8X have this issue too

Answer 95 · 2019-06-14T04:55:52.000Z

I can also confirm the crashes are gone but we are also seeing quite poor performance in lower end devices. Gotta say it's extremely disappointing considering we've been waiting to upgrade to RN58/RN59 for the more modern JSC.

Same here. Old RN on Android was slow and crashy, new RN is fast and crashy and with this fix new RN is stable and slow. Seems we can't have it all on Android. 🙈

Answer 96 · 2019-06-18T00:59:25.000Z

Dears,

I am so sorry that the performance acted bad for the no-JIT version.
And sorry I don't have solutions right now.
It is hard for me to troubleshoot such issue that I was unable to reproduce.
Hopefully someone from the community could help to dig the problem.

JSC for RN is OSS at https://github.com/react-native-community/jsc-android-buildscripts.
It supports to enable debug build by uncommenting line in https://github.com/react-native-community/jsc-android-buildscripts/blob/master/scripts/start.sh#L10.
Attaching gdb or lldb to debug natively, maybe there will be some clue.
The crash might violate some RELEASE_ASSERT in https://trac.webkit.org/browser/webkit/releases/WebKitGTK/webkit-2.22.6/Source/JavaScriptCore/jit/JITOperations.cpp#L1067, but not sure how the problem going to the state.

Answer 97 · 2019-06-18T02:25:15.000Z

Thanks for all your work on this and jsc-android-buildscripts @Kudo. It's been amazing following your progress! Is there anything we (the community watching this issue) can do to help? I believe @tuncaulubilge had a mostly stable repro case.

Maybe the internal facebook react-native team has jsc experts?

Answer 98 · 2019-06-18T02:58:11.000Z

I have just faced this issue, only happens on REAL DEVICE, LENOVO A701a48, RUNNING ANDROID 6.
deleting "arm64-v8a", "x86_64" from

ndk {
            abiFilters "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
 }

did solve it but felt abit hack-y.

Hope there's update from RN's team soon :(

Answer 99 · 2019-06-19T13:21:48.000Z

Dears,

Here is probably my last try - to use newer WebKit version.
@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg is based on WebKitGTK 2.24.2, with baseline JIT but no DFG JIT.
A notable change is that newer WebKit changed JIT bytecode format.
x86's JIT is not supported and armeabi-v7a JIT support is from community (Thanks Igalia).
Since the crash happens only on arm64, the new version is still worth to try.

The detailed steps to integrate this version is in https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file-steps_for_webkitgtk_2_24_2-md.
notable change is that 241213 -> 245459 from previous JSC version and make sure to have 245459.9000.0 in adb log.
Please help to verify this experimented JSC.
Hopefully we have luck this time. 🤞

@benoitdion thanks for your encourage ❤️