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

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"
        }```

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

Screenshot for reference

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<PHONE_NUMBER>7e048c  /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (WTFCrash+16)
#01  pc<PHONE_NUMBER>0be650  /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i+24)
#02  pc<PHONE_NUMBER>489f2c  /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
#03  pc<PHONE_NUMBER>19e27c
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

#24260

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

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

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

@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.

@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?

Also happening on 0.58.5. Galaxy S7. Android 6.0.

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.

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.55<IP_ADDRESS>56338
      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<EMAIL_ADDRESS>  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<EMAIL_ADDRESS>            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<EMAIL_ADDRESS>  0x749d1865 (Missing)
45 (Missing)                              0x12c2fa8e (Missing)
46 system<EMAIL_ADDRESS>  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<EMAIL_ADDRESS>  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<EMAIL_ADDRESS>            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<EMAIL_ADDRESS>  0x749d1865 (Missing)
45 (Missing)                              0x12c2fa8e (Missing)
46 system<EMAIL_ADDRESS>  0x741f0347 (Missing)
47 (Missing)                              0x70d3b9ca (Missing)
48 (Missing)                              0x12c2fa8e (Missing)
49 (Missing)                              0x12c2fa8e (Missing)
50 (Missing)                              0x70abe4f6 (Missing)
51 (Missing)                              0x70aadb2e (Missing)

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<PHONE_NUMBER>0b1acc  x17  000000700bc121a8  x18<PHONE_NUMBER>ecfc88  x19  000000700fed7e80
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x20<PHONE_NUMBER>8cf560  x21  0000006ffd4c8070  x22  000000700bc00000  x23  0000006ff9616ca0
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x28  ffff000000000002  x29<PHONE_NUMBER>8cf560  x30<PHONE_NUMBER>408484
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x24<PHONE_NUMBER>000007  x25<PHONE_NUMBER>000000  x26<PHONE_NUMBER>000000  x27  ffff000000000000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x8   00000000bbadbeef  x9<PHONE_NUMBER>4b19d0  x10<PHONE_NUMBER>000000  x11  0000006ffc4f0000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x0<PHONE_NUMBER>8cf3c8  x1<PHONE_NUMBER>8cf3c8  x2<PHONE_NUMBER>000000  x3<PHONE_NUMBER>0000a8
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    sp<PHONE_NUMBER>8cf400  pc<PHONE_NUMBER>40848c  pstate 00000000a0000000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x4   000000700bfaee80  x5   0000006ff62a4980  x6   0000006ffa6a6820  x7<PHONE_NUMBER>000000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG|    x12<PHONE_NUMBER>000000  x13  000000700b617c00  x14<PHONE_NUMBER>000002  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<PHONE_NUMBER>1afe80  <anonymous:000000700bdff000>
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG|    #02 pc<PHONE_NUMBER>489f2c  /data/app/com.profibackoffice.reactnative-1/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG|    #01 pc<PHONE_NUMBER>0be650  /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<PHONE_NUMBER>7e048c  /data/app/com.profibackoffice.reactnative-1/lib/arm64/libjsc.so (WTFCrash+16)

Adding this to your android/app/build.gradle may fix it:
packagingOptions {
      pickFirst '**/libjsc.so'
      pickFirst '**/libc++_shared.so'
}

See https://github.com/react-native-community/jsc-android-buildscripts/pull/95
Testing this now.

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

16 апр. 2019 г., в 19:12, Andrew Jack<EMAIL_ADDRESS>написал(а):
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 https://github.com/react-native-community/jsc-android-buildscripts/pull/95
Testing this now.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/facebook/react-native/issues/24261#issuecomment-483728028, or mute the thread https://github.com/notifications/unsubscribe-auth/AEO_1BMzddSncn2DtQeDcx_y1KIz0ZSGks5vhfaJgaJpZM4cX_xB.

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?

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)

Didn't work, I thought correcting the jsc-android-buildscripts config might work.

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.

@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.

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

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

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

same issue on REDMI NOTE 4X Android 7.0 and huawei HRY AL00A Android 9
AutomaticThread
SIGSEGV(SEGV_MAPERR)
1 #00 pc<PHONE_NUMBER>42c064 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
2 #01 pc<PHONE_NUMBER>429638 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
3 #02 pc<PHONE_NUMBER>429d28 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
4 #03 pc<PHONE_NUMBER>41664c /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
5 #04 pc<PHONE_NUMBER>7ea4cc /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
6 #05 pc<PHONE_NUMBER>7eabcc /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
7 #06 pc<PHONE_NUMBER>7e0fec /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
8 #07 pc<PHONE_NUMBER>7ee4fc /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
9 #08 pc<PHONE_NUMBER>7ffdb8 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
10 #09 pc<PHONE_NUMBER>083550 /system/lib64/libc.so (__pthread_start(void*)+36) [arm64-v8a]
11 #10 pc<PHONE_NUMBER>0241a0 /system/lib64/libc.so (__start_thread+68) [arm64-v8a]
12 java:
13 [Failed to get Java stack]

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.

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

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
    }```

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

Hi. We've found that:

The fix to remove 64-bit support does work
We have had users fix this problem themselves by restarting their phone (no need to switch to 32-bit app)

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

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).

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<PHONE_NUMBER>09e144
#01  pc<PHONE_NUMBER>0a4a70

This issue is already identified on the webkit repo. I have commented there when I discovered this issue months ago: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/327#issuecomment-436781890
It would be great to coordinate the efforts.
I confirm everything that is said here, plus an extra info: I repro this crash with an older RN version: 0.55.0

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? https://github.com/react-native-community/jsc-android-buildscripts/pull/95

@AndrewJack The new release just for WebKit security patches & removing libc++_shared.so for https://github.com/facebook/react-native/pull/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 https://github.com/react-native-community/jsc-android-buildscripts/issues/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.
https://github.com/react-native-community/jsc-android-buildscripts/issues/84#issue-407898908

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.

@quietbits, most of the logs related to these issues are not super helpful, but to get it out:
Look for when the crash occurs—it'll look something like this:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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.

To get the symbolicated backtrace, I used to combine adb logcat and ndk-stack
For example, targeting RN 059 stock JSC (which is<EMAIL_ADDRESS>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

Any update on this issue?

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.

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

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

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.

@marlonchalegre

@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.

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.

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

With latest 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

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

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

@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.

@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.

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

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

@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.

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

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

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

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.

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

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

@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).

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 where I have to manually build for release)

@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.

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.

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<PHONE_NUMBER>.0 (ref source code here)
yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg' and confirmed adb logcat with version<PHONE_NUMBER>.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

test builds created and sent to testers, inc. the problematic S7 Edge. I'll report back when I get feedback.

@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]

@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<PHONE_NUMBER>.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>

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)

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

@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.

@Kudo UPDATE
The backtrace reported back through the developer console for the original problem (repeatable crashes on, for me exclusively, Samsung S7 Edge + Android 7.0) looks like so:
 #00  pc<PHONE_NUMBER>7e048c  /data/app/org.ifsc.boulder14-1/lib/arm64/libjsc.so (WTFCrash+16)
 #01  pc<PHONE_NUMBER>0be650  /data/app/org.ifsc.boulder14-1/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i+24)
 #02  pc<PHONE_NUMBER>489f2c  /data/app/org.ifsc.boulder14-1/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
 #03  pc<PHONE_NUMBER>2149a8  <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<PHONE_NUMBER>4886ac  /data/app/org.ifsc.boulder14-ECb5NhJUQgyp_UkWAZLdKg==/lib/arm64/libjsc.so (operationLinkDirectCall+176)
  #01  pc<PHONE_NUMBER>43ad90  <anonymous>

Although I've managed to crash the test app twice, each time with the same signature, the crash is not systematically repeatable.  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

@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.

@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.

@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 it 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.

@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<EMAIL_ADDRESS>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.

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

@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.
https://github.com/react-native-community/jsc-android-buildscripts/pull/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.

This code saves lifes

Guys, check this solution - it saved my life

@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 .

#https://github.com/facebook/react-native/issues/25060

#25060

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

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

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

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

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%.

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 for your hardwork. But when i try this version my app already crash on Samsung Galaxy Note FE (Android 9.0 Pie)

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.

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

@yenda of 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

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

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

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.

Huawei Honor 8X have this issue too

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. 🙈

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.

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.

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 :(

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<PHONE_NUMBER>.0 in adb log.
Please help to verify this experimented JSC.
Hopefully we have luck this time. 🤞
@benoitdion thanks for your encourage ❤

@Kudo @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg works fine!
Can confirm that the crash that was happening with RN v0.59, upon using the above JSC, has disappeared. Tested in Google Nexus 6, others will be confirmed after roll out.
Thanks!!

@Kudo  I can confirm @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg works for me as well. No crash occur in Samsung Galaxy S7 SM-G930FD that was happening earlier with RN v0.59 and has been fixed with no-jit or  jsc-android v241213.2.0.

I haven't had the chance to integrate this new build yet as I have some other project milestones getting in the way but plan to do so as soon as these are out of the way.
@Kudo 's original no-dfg builds fixed 99% of the crashes that I had seen and whilst I was able to stimulate a single crash, I was not able to repeat it.
I believe that @tuncaulubilge was able to reproduce crashes with the no-dfg original builds, so it would be interesting to see what he makes of this new build.

@rimzici @dishantwalia @timhatch Thanks for your help.
@tuncaulubilge If you have available time, could you please help to verify the latest experimented version?
IIRC, only you and @timhatch reported crashes from the "241213-fix-clear-cache-no-dfg" last time.
Hopefully we could fix the crashes by the updated version.
Thank you.

@Kudo
Error when loading lib: dlopen failed: "/data/data/com.amiclient.qa/lib-main/librealmreact.so" is 32-bit instead of 64-bit lib hash: 28b81ed6ba5d3bb31c51509ac8150cd4 search path is /data/app/com.amiclient.qa-1/lib/arm64
have this issue after integrated @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg on ZTE Blade, Samsung S8, OnePlus 6. Only on Motorola Z2 Android 7.1.1 started build !

@Kudo
Error when loading lib: dlopen failed: "/data/data/com.amiclient.qa/lib-main/librealmreact.so" is 32-bit instead of 64-bit lib hash: 28b81ed6ba5d3bb31c51509ac8150cd4 search path is /data/app/com.amiclient.qa-1/lib/arm64
have this issue after integrated @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg on ZTE Blade, Samsung S8, OnePlus 6. Only on Motorola Z2 Android 7.1.1 started build !

This seems related to realm please check https://github.com/realm/realm-js/issues/2261#issuecomment-468691502

@Kudo Once again, thanks for the great work! Unfortunately, I've moved to a new project and no longer have access to the old project. I'll try to reach my old teammates and get someone to give this a try.
We were having crashes especially on reactRootView.unmountReactApplication, which triggers garbage collection, leading to the occasional crashes. You might be able reproduce it with a sample app, creating and destroying ReactRootViews.

@Kudo
Error when loading lib: dlopen failed: "/data/data/com.amiclient.qa/lib-main/librealmreact.so" is 32-bit instead of 64-bit lib hash: 28b81ed6ba5d3bb31c51509ac8150cd4 search path is /data/app/com.amiclient.qa-1/lib/arm64
have this issue after integrated @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg on ZTE Blade, Samsung S8, OnePlus 6. Only on Motorola Z2 Android 7.1.1 started build !

This seems related to realm please check realm/realm-js#2261 (comment)
realm/realm-js#2221

Thank you so much! Just had to update realm to 2.28.
@Kudo special thanks. My app already works correctly !

@Kudo I've rebuilt a version of a previously-affected app with the same build configuration as in previous tests but using @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg.
No crashes or hangs so far - I'll see if I can stress the app across the weekend and report back if I encounter any issues.

@timhatch Thank you so much and please take your time during weekend.
Crossing fingers to hear good news from you next time.

I can't build with the patch. I am getting the following error from the FBSDK:
`Task :react-native-fbsdk:compileReleaseJavaWithJavac FAILED
/Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBAppEventsLoggerMod
ule.java:209: error: cannot find symbol
@ReactMethod(isBlockingSynchronousMethod = true)
^
symbol:   method isBlockingSynchronousMethod()
location: @interface ReactMethod
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
FAILURE: Build failed with an exception.`

@wmonecke The issue seems weird to me. I didn't touch any java code or gradle dependencies in the JSC AAR.
Could you please check the issue, or briefly describe how you apply the patch?
I guess you accidentally use old RN dependency and
you could verify by ./gradlew :app:dependencies | grep 'com.facebook.react:react-native:' (please make sure the returned RN version is that you expected).

I can't build with the patch. I am getting the following error from the FBSDK:
Task :react-native-fbsdk:compileReleaseJavaWithJavac FAILED
/Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBAppEventsLoggerMod
ule.java:209: error: cannot find symbol
     @ReactMethod(isBlockingSynchronousMethod = true)
                                                ^
  symbol:   method isBlockingSynchronousMethod()
  location: @interface ReactMethod
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error

FAILURE: Build failed with an exception.

@wmonecke you have to add both (react-native and kudo ci) maven repository to get it compiled
maven {
// All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
url "$rootDir/../node_modules/react-native/android"
}
maven{
// Local Maven repo containing AARs with JSC library built for Android
url "$rootDir/../node_modules/@kudo-ci/jsc-android/dist"
}

@Kudo No problems with @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg. No application hangs or crashes.

@Kudo No problems with @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg. No application hangs or crashes.

@Kudo Please push that fix in jsc-android-buildscripts and publish a version. So we can roll out this in our production apps https://github.com/react-native-community/jsc-android-buildscripts.

@timhatch Awesome! Specially thanks for your verficiation. Will push the JSC changes into RN soon.
@dishantwalia Yes, ongoing. Thank you.

Thanks Kudo for all your work on this. Can you (or someone else who knows what is happening) just please guide me in the right direction for implementing this fix (I realise it's a work in progress).
I'm currently on RN 0.59.9. With the changes being rolled out, will an updated version of RN become available something like 0.59.10 or should I instead install jsc-android-buildscripts as a third party package, and implement for 0.59x as per the documentation?

@Kudo No problems either with your last version. Great work! 💪

Thanks @Kudo , I am the same question @jacquesdev is asking 0.59.10 or jsc-android-buildscripts?

@Kudo @dishantwalia
Thanks! I was only keeping:
 maven {
            // workaround for crash on 64 bit devices - remove once RN 59+ has resolved issue.
            // issue: https://github.com/facebook/react-native/issues/24261
            url "$rootDir/../node_modules/@kudo-ci/jsc-android/dist"
        }

withing build.gradle

@Kudo unfortunately the problem is still there (Galaxy S7, Android7). I've tried @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg.
I've also tried no-JIT version, which did not help. I didn't manage to make it such that the "JavaScriptCore" version is printed out in adb logcat using the grep you provided, neither did I see any mention of JavaScriptCore in the log itself by manually looking.
I can reproduce the crash quite frequently. It does not always crash at the same place.

Hi, @ChrisEelmaa I just updated, follow the steps carefully, this really works for me.
https://github.com/react-native-community/jsc-android-buildscripts#for-react-native-version-059

I believe we're having the same issue.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.groundspeak.react.adventures <<<

backtrace:
  #00  pc<PHONE_NUMBER>7e048c  /data/app/com.groundspeak.react.adventures-1/lib/arm64/libjsc.so
  #01  pc<PHONE_NUMBER>0be650  /data/app/com.groundspeak.react.adventures-1/lib/arm64/libjsc.so
  #02  pc<PHONE_NUMBER>489f2c  /data/app/com.groundspeak.react.adventures-1/lib/arm64/libjsc.so
  #03  pc<PHONE_NUMBER>25fd98  <anonymous>

By Android version:

Version
Number
Percent

Android 7.0
66
100.0%

By Device:

Device
Number
Percent

hero2lte
26
39.4%

herolte
24
36.4%

heroltebmc
16
24.2%

I have been also getting the Galaxy S7 crash after updating to RN 0.59.9.
The current npm version of jsc-android still makes the app crash, but using @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg and JSC version<PHONE_NUMBER>.0 fixed the crash for me on S7.

@ChrisEelmaa The "JavaScriptCore.Version " log in adb logcat is a way confirming to pick correct JSC version.
Because RN 0.59 has builtin libjsc.so and pickFirst '**/libjsc.so' is not reliable in my opinion.
An alternative way to confirm the JSC version would be following steps:

unzip /path/to/app.apk
strings jni/arm64-v8a/libjsc.so|grep -C 1 JavaScriptCore.Version

The output should be something like:
$ strings jni/arm64-v8a/libjsc.so|grep -C 1 JavaScriptCore.Version
API Wrapper
JavaScriptCore.Version
245459.9000.0

@Kudo thanks for your fix, it seems to prevent the hell to occur.
My 2 cents there: I don't have a jni folder but a lib one instead so using this command to check the version after unzipping:
$ strings lib/arm64-v8a/libjsc.so | grep -C 1 JavaScriptCore.Version
API Wrapper
JavaScriptCore.Version
245459.9000.0

Thanks @Kudo
I previously had react-native 0.58.3, I see people mention 0.59 all the time, so I decided also to update. The combination of having 0.59.0 and @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg seemed to do the trick for me.
I can no longer produce the crash.

Does anyone know if a fix for this issue will be in the next RN release?

Does anyone know if a fix for this issue will be in the next RN release?

https://github.com/react-native-community/jsc-android-buildscripts#for-react-native-version-060-and-newer

@kristerkari
Just to confirm the steps you followed.
You followed instructions here, https://github.com/react-native-community/jsc-android-buildscripts#for-react-native-version-059
But you swapped instead of adding "jsc-android": "241213.x.x",, you added @kudo-ci/jsc-android": "^245459.9000.0 to your package.json? Did youy make any other changes?
For example I see that in build.grade, you should add implementation "org.webkit:android-jsc:r241213", does that line have to change as well, and if yes what should it be?
I keep on getting the build error Could not find org.webkit:android-jsc:r241213. orCould not find org.webkit:android-jsc:r245459.9000.0. So I'm guessing my issues is using the wrong reference there, but can't quite tell what it should be.

@jacquesdev follow the steps in this guide: https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file-steps_for_webkitgtk_2_24_2-md

Dears,
Just to update that with @kmagiera's help, my patch has been published as<EMAIL_ADDRESS>I've sent https://github.com/facebook/react-native/pull/25426 to have the updated JSC into RN.
And @kelset also have it into RN 0.60 RC.
Hopefully we could finally fix and close this issue.
Shout out to people here especially for the help to verify my experimented versions back and forth.
We are so called RN community!

Thanks @Kudo!  Do you have any idea whether this has any chance making an 0.59.x release, or is it likely to be just in 0.60?

It 'd be awesome if we can get it in 0.59.x
0.60 has a lot of breaking changes with AndroidX & external libs.

+1 for us, getting it into 0.59.x would solve a lot of problems for our
apps.
Don't really want to head into 0.60 because of the Android X support in
libraries so far.
The pickFirst for JSC hasn't worked for us, must be one of our native libs
causing an issue but it seems to always pick the rn internal version.
(Clean project worked though, so must be one of our deps causing it)
Kirk
On Sat, 29 Jun 2019, 19:35 Anurag Dadheech<EMAIL_ADDRESS>wrote:

It 'd be awesome if we can get it in 0.59.x
0.60 has a lot of breaking changes with AndroidX & external libs.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ25TBIFBOI3QWMSPXLP46TN3A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY355CI#issuecomment-506977929,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABPHZ2D5WUEM4S3242ZTYTP46TN3ANCNFSM4HC77RAQ
.

Hi can i know where to add this "@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg" ?

Hi @Kudo thanks for your awesome work!
In the old WebKit with no DFG JIT, crashes still occur but the newer WebKit 2.24.2 with no DFG JIT seems to fix it. I'm wondering whether it's worth trying this new WebKit with DFG JIT enabled in order to allow the highest possible performance if it works.

I agree with some comments before it would be better to have a 0.59.10 with this fix because it is going to be harder to upgrade to 0.60 @Kudo

Have the same issue here,
We can't upgrade to 0.60 because react-native-maps doesn't support AndroidX yet, can't push our updates to 0.59.X because S7 & S7 plus crashes.
This really an issue for businesses really on react-native
Is there any workaround for this?

Have the same issue here,
We can't upgrade to 0.60 because react-native-maps doesn't support AndroidX yet, can't push our updates to 0.59.X because S7 & S7 plus crashes.
This really an issue for businesses depends on react-native
Is there any workaround for this?

Have the same issue here,
We can't upgrade to 0.60 because react-native-maps doesn't support AndroidX yet, can't push our updates to 0.59.X because S7 & S7 plus crashes.
This is really an issue for businesses depends on react-native
Is there any workaround for this?

I agree with @adnkh, we cant upgrade to AndroidX now, but we need to solve the 0.59 crashes.

You do not need to upgrade to 0.60 to consume the fix. You should be able to follow the instructions at https://github.com/react-native-community/jsc-android-buildscripts/#for-react-native-version-059. The version you want to install is 245459.0.0 or greater.

Hi @benoitdion ,
Yes, it is possible to consume even though is not in the main library, in fact, I followed these instructions https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 . and it worked
But I don't think this is a permanent solution and neat because of the many things you need to add to your Android project, I think a hotfix in main RN would be more convenient from a developer point of view and it solves many crashing issues on Android apps

@benoitdion yes, but it is a workaround, an official fix published as 0.59.10 would be better.

Thanks @Kudo
Use @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg reduced most of the crashes
But there are still a few crashes in the production
xiaomi MIX 3 XiaoMi/MIUI Android 9,level 28 arm64-v8a
1 #00 pc<PHONE_NUMBER>0f7748 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const+16) [arm64-v8a]
2 #01 pc<PHONE_NUMBER>143fe8 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const+48) [arm64-v8a]
3 #02 pc<PHONE_NUMBER>12f0a8 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&)+556) [arm64-v8a]
4 #03 pc<PHONE_NUMBER>139484 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::runConstraint(JSC::ConcurrentJSLocker const&, JSC::VM&, JSC::SlotVisitor&)+40) [arm64-v8a]
5 #04 pc<PHONE_NUMBER>13900c /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)+1044) [arm64-v8a]
6 #05 pc<PHONE_NUMBER>1fb9c4 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+324) [arm64-v8a]
7 #06 pc<PHONE_NUMBER>1f8e90 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::SlotVisitor::drain(WTF::MonotonicTime)+132) [arm64-v8a]
8 #07 pc<PHONE_NUMBER>1f96bc /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)+580) [arm64-v8a]
9 #08 pc<PHONE_NUMBER>1e41a0 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_17E3runEv+580) [arm64-v8a]
10 #09 pc<PHONE_NUMBER>6171ec /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::SharedTask<void ()> > > const&)+40) [arm64-v8a]
11 #10 pc<PHONE_NUMBER>617950 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::ParallelHelperPool::Thread::work()+16) [arm64-v8a]
12 #11 pc<PHONE_NUMBER>60de7c /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+376) [arm64-v8a]
13 #12 pc<PHONE_NUMBER>61b084 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+212) [arm64-v8a]
14 #13 pc<PHONE_NUMBER>646dc8 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::wtfThreadEntryPoint(void*)+4) [arm64-v8a]
15 #14 pc<PHONE_NUMBER>081dac /system/lib64/libc.so (__pthread_start(void*)+36) [arm64-v8a]
16 #15 pc<PHONE_NUMBER>023788 /system/lib64/libc.so (__start_thread+68) [arm64-v8a]

OPPO R9S  Oppo/COLOROS  Android 6.0.1,level 23  arm64-v8a
1 #00 pc<PHONE_NUMBER>0f7748 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const+16) [arm64-v8a]
2 #01 pc<PHONE_NUMBER>143fe8 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const+48) [arm64-v8a]
3 #02 pc<PHONE_NUMBER>12f0a8 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&)+556) [arm64-v8a]
4 #03 pc<PHONE_NUMBER>139484 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::runConstraint(JSC::ConcurrentJSLocker const&, JSC::VM&, JSC::SlotVisitor&)+40) [arm64-v8a]
5 #04 pc<PHONE_NUMBER>13900c /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)+1044) [arm64-v8a]
6 #05 pc<PHONE_NUMBER>1fb9c4 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+324) [arm64-v8a]
7 #06 pc<PHONE_NUMBER>1f8e90 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::SlotVisitor::drain(WTF::MonotonicTime)+132) [arm64-v8a]
8 #07 pc<PHONE_NUMBER>1f96bc /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)+580) [arm64-v8a]
9 #08 pc<PHONE_NUMBER>1e41a0 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_17E3runEv+580) [arm64-v8a]
10 #09 pc<PHONE_NUMBER>6171ec /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::SharedTask<void ()> > > const&)+40) [arm64-v8a]
11 #10 pc<PHONE_NUMBER>617950 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::ParallelHelperPool::Thread::work()+16) [arm64-v8a]
12 #11 pc<PHONE_NUMBER>60de7c /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+376) [arm64-v8a]
13 #12 pc<PHONE_NUMBER>61b084 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+212) [arm64-v8a]
14 #13 pc<PHONE_NUMBER>646dc8 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::wtfThreadEntryPoint(void*)+4) [arm64-v8a]
15 #14 pc<PHONE_NUMBER>0664a4 /system/lib64/libc.so (__pthread_start(void*)+52) [arm64-v8a]
16 #15 pc<PHONE_NUMBER>01ebc4 /system/lib64/libc.so (__start_thread+16) [arm64-v8a]

RMX1901  Oppo/COLOROS  Android 9,level 28  arm64-v8a
1 #00 pc<PHONE_NUMBER>fbb2c0 <unknown>
2 #01 pc<PHONE_NUMBER>5519bc /data/app/com.gezbox.windmessage-vCMpnEKA509f1Di2EyrZ2w==/lib/arm64/libjsc.so (JSC::RegExp::match(JSC::VM&, WTF::String const&, unsigned int, WTF::Vector<int, 0ul, WTF::CrashOnOverflow, 16ul>&)+500) [arm64-v8a]
3 #02 pc<PHONE_NUMBER>5722e8 /data/app/com.gezbox.windmessage-vCMpnEKA509f1Di2EyrZ2w==/lib/arm64/libjsc.so (JSC::stringProtoFuncReplaceUsingRegExp(JSC::ExecState*)+3072) [arm64-v8a]
4 #03 pc<PHONE_NUMBER>dff1ec <unknown>

👋 everyone.
We hear you all, and because of the issues so many of you are having we did one last 0.59.10 patch release to provide you with the new version of the JSC.
Huge thanks to @Kudo for his work on back-porting this to 0.59.
We will not do new 0.59 releases, as it is a challenging work and even harder because we are also working on 0.60 (which will have the new JSC too!).
I'm going to close this as the main core issue has been tackled, but I'd suggest to open a new one for other crashes that you may be experiencing after 0.59.10.

Excellent news !!
Thanks all, especially @kudo !!
On Tue, 2 Jul 2019, 12:29 Lorenzo Sciandra<EMAIL_ADDRESS>wrote:

👋 everyone.
We hear you all, and because of the issues so many of you are having we
did one last 0.59.10 patch release to provide you with the new version of
the JSC.
Huge thanks to @Kudo https://github.com/Kudo for his work on
back-porting this to 0.59.
We will not do new 0.59 releases, as it is a challenging work and even
harder because we are also working on 0.60 (which will have the new JSC
too!).
I'm going to close this as the main core issue has been tackled, but I'd
suggest to open a new one for other crashes that you may be experiencing
after 0.59.10.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZZG2Z764HFNPJB7UVTP5M325A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZA6LHI#issuecomment-507635101,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABPHZ5PYT4F7ZZGQXZKKKLP5M325ANCNFSM4HC77RAQ
.

Thanks for the fix! After upgrading to 0.59.10 do I still need to implement the steps mentioned here?

Thanks a lot for the fix! After upgrading react-native to version 0.59.10, do I still need to implement the steps mentioned here?

Kevin,
After upgrade to RN 0.59.10 you do not need to follow any of the gist
instructions any longer.
K
On Wed, 3 Jul 2019, 15:42 Kevin Etore<EMAIL_ADDRESS>wrote:

Thanks a lot for the fix! After upgrading react-native to version 0.59.10,
do I still need to implement the steps mentioned here
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ6H66HMI6CFMXMR4Y3P5S3DVA5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZEVDYQ#issuecomment-508121570,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABPHZ6UMO5NS4F4OZ7RWPTP5S3DVANCNFSM4HC77RAQ
.

My app still crashes on Meizu M5s M612H Android OS 6 with RN-0.59.10. I've created new issue as @kelset suggested.

Still crashing on Caterpillar S14 (Android 8.0). The fix resolved issue on all other devices. Also created a new issue. Tell me if this is not the right way to do.

Hi guys
My app also crash in some android device when compile in 64bits
Are you using the  react-native-elements package version 1.1.0??
Because the component Header crash my app and also the Avatar component when I put the prop icon or title
Can someone else check if the same thing happens to them?

any s7 owners had the change to test this issue with Hermes?

if i use below app crashes and accepted by google play store
ndk { abiFilters "armeabi-v7a","arm64-v8a","x86","x86_64" }
if i use below app is working but not accepted by google play store
ndk {  abiFilters "armeabi-v7a", "x86" }
please any one help me solving

Still crashes on Moto G7 and Pixel 2 (both Android 9.0) with the 64 bit arm APK. It works fine with the 32 bit arm APK.

@afras21 - this is because the bug exists in the 64 bit version, which the Google Play Store is making mandatory.

@jacquesdev Thanks jacq , now they removed the mandatory and now its working

@afras21 you mean google has lifted the 64bit restriction from playstore?

I have same issue. If I update my project from 0.59.9 to 0.60.4 should I have fix the issue?

I have same issue. I am currently using 0.59.9. If I upgrade to 0.60.x, will the issue be resolved?

Please first to try if 0.59.10 did solve the problems for you.
If not, maybe it's worth to upgrade RN 0.60.4 and turn on Hermes instead.

Repeating what Kudo said, just more giving context and summarizing the previous content of this issue (since it's probably hard to sort through so many comments at this point):
If you have 0.59.9 or below, this is a verified problem with the old JSC. It's the subject of hundreds of comments above (and in other issues). The problem isn't exclusive to 64-bit, but most often occurs with 64-bit.
0.60+ has various breaking changes, especially on Android.
If you don't want to go through that, try 0.59.10 since it has the fix (as described above) integrated directly in the version/build—and it seems to fix the problem for the majority of cases.
There are still cases where there are problems for certain phones (which I've encountered too), see #25494—if you have this, I'd suggest posting your stacktraces to that open issue there. However, if you're saying you have 0.59.9, you can probably fix your problem by going to 0.59.10.

@MalcolmScruggs  @ntorion @harryt2
Have you solved it? How to solve？Thanks

0.59.10 did not resolve it for me. I'll try making the 0.60.x upgrade

@MalcolmScruggs @ntorion @harryt2
Have you solved it? How to solve？Thanks

0.59.10 didn't solve it for me either. I can't upgrade to 0.60.x because some of my dependencies won't work. Got it to compile on Hermes but saw a huge spike in ANRs (Thank God for staged rollout). Still sitting on the Play Store with RN version 0.57.8 but I can't update my app anymore because of the 64 bit requirement. Pretty frustrated and trying to decide whether to just rebuild the entire app with another framework.

@harryt2 @rogerkerse Thanks.
My situation is even worse. The released version has bugs, so I have to upgrade the 64 application. I can't solve this problem at the moment. I am also trying flutter, but not so fast complete replacement.

I actually went through the trouble of bumping React-Native to 0.60.5 and enabling Hermes + 64-bit (which was a pain, as upgrading react-native always is) and I'm still having these issues on several Android phones (including HUAWEI MYA-L41).
I've tried just about everything I've found in other threads without much luck, so I can tell you bumping react-native and using Hermes doesn't fix all of these issues.
The updated react-native + Hermes and 64-bit is amazing on other Android devices I've ran it on and our app has never felt smoother.
However, whenever I test on the specific device I mentioned (Huawei) it crashes instantly or after the app is open for 1-2 seconds without a specific crash message, I don't have any other devices besides that one and a newer Huawei (which works perfectly) so I can't give you more info on other phones.
If anyone has made any progress with this issue or has any ideas for more specifically logging my issues, advice is always welcome and I'm willing to share any information regarding this issue.
Thanks to the people in this thread for offering solutions, but no luck so far. 🙂

@YoranRoels Have you tried running a clean app created by react-native init? I wonder whether the crash is caused by RN itself or some library or code you've written.

@armenbadalyan Thanks for the swift response.
I just set up a new project and tried running it on the device and everything seems well, so in the end it does seem like something with my setup. Is there an efficient way to debug this since my logcat doesn't spew out anything useful besides com.<our_app_id> has been killed?

@GreanBeetle You can use V8 engine on 0.59.10 to get rid of this problem
https://github.com/Kudo/react-native-v8

@GreanBeetle You can use V8 engine on 0.59.10 to get rid of this problem
https://github.com/Kudo/react-native-v8

Can confirm that this solved the issue for us. 64 bit builds with react-native-v8 on 0.59.10 are not crashing anymore and we can finally push updates again on Google Play. Thank you!

I tried the tombstone logging @j-wang mentioned but I've never really used that and it was an immense file which was hard to read, after searching for a while I didn't really seem to find a readable root cause.
After taking the advice of @armenbadalyan, I started wondering if it just wasn't something silly in the start of our app and sure enough when removing the first component's UI, I noticed that the app was running again, stable. So after more digging I noticed that a specific component was given issues where an Image was rendered.
In that component there is a chance that we pass null as the source variable on a react-native Image. Took me a while to look for this an no real clear errors but this finally fixed everything for me and it's running on all our test devices. Still no clue why it didn't fail on our other test device...
Might help other people to simplify the first component of their app to make sure it's not crashing on that code.
TL;DR: This is probably completely off-topic by now, but to whom it concerns: DON'T USE null AS THE source VARIABLE OF Image, it doesn't work on all devices. 😅

@harryt2 yes, me too. I got a huge spike in ANRs after upgraded to RN 0.60.+

A little help to the ones still trying to address the startup crash:

run adb logcat in a console
wait for the console spam to stop
open the crashing app on your device
stop the adb logcat with a Ctrl+c
scroll up and find the crash

It doesn't solve the problem but let you find out something more. I've 2 apps, one is working well with the 64 bit, still struggling on the other one even if they've the same configuration. My crashing device is a One Plus 5t (64 bit)

I've just seen this on a new release of our App, building with RN 59.10, specifically on a Samsung Galaxy Note9 on Android 9. Anyone else seeing a similar issue?

@msspshaw As mentioned above and in the other issue, yes. The new JSC freezes/crashes randomly on certain Android devices because it gets non-deterministically garbage collected—then the entire app crashes.
The solution is to upgrade to 0.60+ and use Hermes, or switch out JSC for v8.

I tried the tombstone logging @j-wang mentioned but I've never really used that and it was an immense file which was hard to read, after searching for a while I didn't really seem to find a readable root cause.
After taking the advice of @armenbadalyan, I started wondering if it just wasn't something silly in the start of our app and sure enough when removing the first component's UI, I noticed that the app was running again, stable. So after more digging I noticed that a specific component was given issues where an Image was rendered.
In that component there is a chance that we pass null as the source variable on a react-native Image. Took me a while to look for this an no real clear errors but this finally fixed everything for me and it's running on all our test devices. Still no clue why it didn't fail on our other test device...
Might help other people to simplify the first component of their app to make sure it's not crashing on that code.
TL;DR: This is probably completely off-topic by now, but to whom it concerns: DON'T USE null AS THE source VARIABLE OF Image, it doesn't work on all devices. 😅

+1 Works for me. I had same problems. Thank you!

Also see it happening on a Samsung Galaxy S7 IO-IL 086 on Android 7.0 RN 0.59.10

@BracketMan Are you using V8 instead of JSC?

@EmilScherdin ahhh no, I am not. Will give it a shot and report back thanks.

@EmilScherdin I can confirm that running on V8 on RN 0.59.10 is working for me, no more crashes.
Thanks!

We experience the same issue on RN 0.59.10 with v8. I see that JIT is not disabled for arm64-v8a and on devices with this architecture we have crashes.

@mmamoyco Do you have the stacktrace of the crash from V8?

@Kudo Yeah I do have the crash log. We have shifted to v8 from jsc because we were experiencing a lot of crashes. But the same is happening using v8. below is the log
#00  pc<PHONE_NUMBER>c31dd8  /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
#01  pc<PHONE_NUMBER>c3437c  /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
#02  pc<PHONE_NUMBER>c30554  /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
#03  pc<PHONE_NUMBER>c33070  /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
#04  pc<PHONE_NUMBER>bf2e94  /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so (v8::internal::ItemParallelJob::Task::RunInternal()+24)
#05  pc<PHONE_NUMBER>a4d660  /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so (v8::platform::DefaultWorkerThreadsTaskRunner::WorkerThread::Run()+56)
#06  pc<PHONE_NUMBER>a4a074  /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
#07  pc<PHONE_NUMBER>067ec4  /system/lib64/libc.so (__pthread_start(void*)+36)
#08  pc<PHONE_NUMBER>01f2f4  /system/lib64/libc.so (__start_thread+68)

We had this exact issue and were able to fix it by doing the following:

⛄ These directions are not the same as on the jsc-android README. We've modified version numbers and some signifiers. The canary version of jsc does not fix the issue. It's the version after jsc-android@canary that's needed, see: This Patch for the original fix that was merged into the react-native repo. Thanks to @ravali121 for helping solve this.

Add jsc-android to the "dependencies" section in your package.json:

dependencies {
+  "jsc-android": "^245459.0.0",

then run npm install or yarn (depending on which npm client you use) in order for the new dependency to be installed in node_modules

Modify android/build.gradle file to add the new local maven repository packaged in the jsc-android package to the search path:

allprojects {
    repositories {
        mavenLocal()
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url "$rootDir/../node_modules/react-native/android"
        }
+       maven {
+           // Local Maven repo containing AARs with JSC library built for Android
+           url "$rootDir/../node_modules/jsc-android/dist"
+       }
    }
}

Update your app's build.gradle file located in android/app/build.gradle to add the JSC dependency.  Please make sure the dependency is before the React Native dependency.

dependencies {
+   // Make sure to put android-jsc at the top
+   implementation 'org.webkit:android-jsc:+'
    compile fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
    implementation "com.facebook.react:react-native:+"  // From node_modules
}

Update your app's build.gradle file located in android/app/build.gradle to use first matched JSC library.

android {
    // ...
+   packagingOptions {
+       pickFirst '**/armeabi-v7a/libc++_shared.so'
+       pickFirst '**/x86/libc++_shared.so'
+       pickFirst '**/x86_64/libc++_shared.so'
+       pickFirst '**/arm64-v8a/libc++_shared.so'
+       pickFirst '**/libjsc.so'
+    }
}

could anybody help to answer this question?
https://github.com/react-native-community/jsc-android-buildscripts/issues/127

DON'T USE null AS THE source VARIABLE OF Image, it doesn't work on all devices. 😅

I hate to just quote you but I nearly missed your solution in the noise of this thread. Thank you so much @YoranRoels!! This saved the day!

I find a  Online real machine test website,  In there i chose GALAXY S7 Edge and android 7.0 os, Unfortunately it dosen't happen crash, and i try to use @YoranRoels method set source variable of Image to {null} and {{ uri: null }} but it still not crash,Horrible i don't even know how it happened, Can anyone help me.


Update SinkRunner.java

when stopping SinkRunner, if there still exists datas in the channel, they would be lost.

when stopping SinkRunner, if there still exists datas in the Memory channel, they would be lost. So check if the channel is empty


Plotly on koalas dataframes

I can easily use plotly's interactive charts by below 2 lines of code:
import pandas as pd
pd.options.plotting.backend = "plotly"
However, unable to use Plotly with Koalas Dataframes. Is there a workaround or can there be an enhancement to include this feature?

I don't think there is an easy workaround at this moment.

So, what is an alternative, of a visualization library which works both on pandas and koalas without needing much of code change? Visualization is an important component during EDA and Data Analysis and right now I feel this is a limitation for being able to move pandas codes to koalas.

Currently the only alternative is to use matplotlib for now. I am happy to review and merge if somebody works on it in Koalas.

I am running this on a colab environment. Unfortunately getting an interactive plot from matplotlib on colab is not supported. So, I need to get back to pandas to be able to create interactive plots.

I'd like to work on implementing the matplotlib features for plotly, if this is a required feature.

Thanks Ratin. Interactive visualization is the way to go in my opinion and
matplotlib has lot of limitations when it comes to that.
On Wed 8 Jul, 2020, 12:26 AM Ratin Kumar<EMAIL_ADDRESS>wrote:

I'd like to work on implementing the matplotlib features for plotly, if
this is a required feature.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/databricks/koalas/issues/1626#issuecomment-655057833,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHQROEMQDLPCUUBU5B4ES6TR2NVWVANCNFSM4OPLA75Q
.

@DumbMachine Please feel free to go ahead and submit a PR. Thanks for working on this!

Plotly backend for pandas currently supports:

line
scatter
area
bar
box
histogram

So I will start by implementing these.

Small update, Made some changes to get plotly up and working. Below is a small example. If this does it, then I will open the PR.

(sorry about the image size)

Great start! Pandas has a feature to enable a visualization library by
selection -
import pandas as pd
pd.options.plotting.backend = "plotly"
Would we be able to setup something similar for Koalas? This would also,
enable a pandas-like approach to visualization. I would think this would
keep the syntax closer and similar to pandas style of enabling and using
plotly.
On Wed, Jul 8, 2020 at 5:32 PM Ratin Kumar<EMAIL_ADDRESS>wrote:

Small update, Made some changes to get plotly up and working. Below is a
small example. If this does it, then I will open the PR.
[image: image]
https://user-images.githubusercontent.com/23381512/86916108-b52e4e80-c140-11ea-828a-15206814d6a0.png
(sorry about the image size)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/databricks/koalas/issues/1626#issuecomment-655475589,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHQROEKOQWVBFF5X4SWUQFLR2RN6BANCNFSM4OPLA75Q
.

Koalas support such options - https://koalas.readthedocs.io/en/latest/user_guide/options.html. We could implement this in a similar way.

Awesome work!
Yeah, shall we have a conf ks.options.plotting.backend = "plotly" and switch the behavior to follow the pandas' usage?
FYI: the file for options is https://github.com/databricks/koalas/blob/master/databricks/koalas/config.py

Have opened a PR. The plotting works as expected. I have tested the

ks.options.plotting.backend = "plotly"
ks.options.plotting.backend = "pandas_bokeh"

options. Using the options strategy allows for compatibility with other libraries as well like pandas_altair.

Hi,
I am on Koalas 1.0.1. But unable to use the feature -
[image: image.png]
[image: image.png]
Thanks
Ayush Jain
On Tue, Jul 14, 2020 at 4:15 PM Hyukjin Kwon<EMAIL_ADDRESS>wrote:

Closed #1626 https://github.com/databricks/koalas/issues/1626 via #1639
https://github.com/databricks/koalas/pull/1639.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/databricks/koalas/issues/1626#event-3543597470, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHQROEJR5JZY2PGDFR227QDR3QZMPANCNFSM4OPLA75Q
.

@jainayush007 This feature will be available in the next release.

Ah I see! Do we know when would the next release happen?
On Tue, Jul 14, 2020 at 11:17 PM Takuya UESHIN<EMAIL_ADDRESS>wrote:

@jainayush007 https://github.com/jainayush007 This feature will be
available in the next release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/databricks/koalas/issues/1626#issuecomment-658319801,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHQROENEWIFPKS2OWENPIB3R3SKZLANCNFSM4OPLA75Q
.

The current target is 7/16 2020. https://koalas.readthedocs.io/en/latest/development/contributing.html#release-cadence

Hi,
I started using this. Seems like is a scale issue here. Here is an example -
This is the URL of the dataset - '
https://raw.githubusercontent.com/srivatsan88/YouTubeLI/master/dataset/coronavirus/corona_dataset_latest.csv
'
Koalas + Plotly -
[image: image.png]
Pandas + Plotly -
[image: image.png]
Thanks
Ayush Jain
On Tue, Jul 14, 2020 at 11:36 PM Takuya UESHIN<EMAIL_ADDRESS>wrote:

The current target is 7/16 2020.
https://koalas.readthedocs.io/en/latest/development/contributing.html#release-cadence
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/databricks/koalas/issues/1626#issuecomment-658329448,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHQROEOGGJBZPFR567JFY6LR3SNC5ANCNFSM4OPLA75Q
.

Hi, we can't see the images.
Could you upload the image somewhere we can see, and also could you elaborate what the issue is?
Btw, I guess opening a new issue would be better?
Thanks.

Sure, I just created issue  #1817


Revert "Guide navigation is currently confusing"

Fixes nodegit/nodegit#494
Not sure what happened, but it doesn't look like the documentation changes made it into master?

Add fixes from nodegit/nodegit@2fe55cc.
Fix basic install links at the top of the guide pages.

I don't know what happened either, but this looks great, thanks!


core wallet needs to be enabled to run eps #133

Solution to issue #133 by enabling the bitcoin core wallet. As commenting out disablewallet=1 has not worked, the value is changed in this proposal.

Thanks for the pull request, great initiative! I streamlined the config update a bit, hope you don't mind.

Of course I don't mind! Thank you.


issue in showOtherDates when using two flags - out_of_range|decorated_disabled

I ran into this issue when I use out_of_range|decorated_disabled these two flags combined in showOtherDates.
The code which checks for decorated_disabled flag ignores the out_of_range. It is only checking if the given day isInRange.
if (isDecoratedDisabled && showDecoratedDisabled) {
    shouldBeVisible |= isInMonth && isInRange;
}

It should check if the out_of_range is enabled as well.
if (isDecoratedDisabled && showDecoratedDisabled) {
    shouldBeVisible |= isInMonth && (isInRange || showOutOfRange);
}

any thoughts?

I believe this is working as there is this line above:
        if (!isInRange && showOutOfRange) {
            shouldBeVisible |= isInMonth;
        }


Add AmazonCognitoReadOnly permission to the elasticbeanstalk user

Do you need a write permission? Can you add all the permissions you added manually, and I'll add them

Do you need a write permission? Can you add all the permissions you added manually, and I'll add them

arn:aws:iam::aws:policy/AmazonCognitoReadOnly


Support for Numpy BitGenerators PR#4: Generator().integers() Support.

This PR builds on top of #8040
Adds the following distributions as Generator methods:

Generator().integers()

This PR is ready for another round of review.

I ran d3618598530e36ad704e15dbc228b089c4f9cefa through the farm as numba_smoketest_cpu_nprgen_21 and it passed.

@kc611 thank you for the patch @sklam thank you for the merge. Excited to see this large PR finally cross the line!


define a mathematical abstraction for converting linOp to stacked-slices

will close as completed once implementation for mul, rmul, div and mul_element are done.


Getting cannot parse error when using a javascript config file

Input code

node_modules/.bin/jsdoc -c ./jsdoc.js

JSDoc configuration

module.exports = {
  "tags": {
    "allowUnknownTags": true
  },
  "source": {
    "includePattern": ".+\\.js(doc)?$"
  },
  "plugins": [],
  "templates": {
    "cleverLinks": false,
    "monospaceLinks": false,
    "default": {
      "outputSourceFiles": true
    },
    "systemName"      : "Gue",
    "footer"          : "",
    "copyright"       : "Copyright © 2017",
    "navType"         : "vertical",
    "theme"           : "oblivion",
    "linenums"        : true,
    "collapseSymbols" : false,
    "inverseNav"      : true
  }
};

JSDoc debug output

Cannot parse the config file ./jsdoc.js: SyntaxError: Unexpected token m in JSON at position 0

Expected behavior
jsdoc.js uses the exported config

Current behavior
jsdoc errors

Your environment

Software
Version

JSDoc
3.6.0

Node.js
8.2.1

yarn
0.27.5

Operating system
OSX

-c expects a JSON file, and it fails given that you are passing a JavaScript module.
Looks like you are asking for a new feature.

I can't say for<EMAIL_ADDRESS>(version used in the initial issue), but passing a javascript config file works with<EMAIL_ADDRESS>