Merci d'avoir soumis votre problème. Pouvez-vous revoir votre description et vous assurer que le modèle de problème a été rempli dans son intégralité?

👉 Cliquez ici si vous souhaitez revoir

Merci d'avoir soumis votre problème. Pouvez-vous revoir votre description et vous assurer que le modèle de problème a été rempli dans son intégralité?

👉 Cliquez ici si vous souhaitez revoir

Actualisé

Capture d'écran d'erreur de Logcat pour référence

publication d'une version fractionnée 64 bits Je reçois également ce crash au lancement sur Galaxy S7 et Galaxy S7 Edge avec Android 7.0
Android vitals montrant:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) WTFCrash
retour arrière:
# 00 pc 00000000007e048c /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (WTFCrash + 16)
# 01 pièce 00000000000be650 /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i + 24)
# 02 pc 0000000000489f2c /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (operationLinkDirectCall + 1120)
# 03 pc 000000000019e27c

sur Crashlytics pour les appareils que je reçois:
Exception fatale: com.facebook.react.common.c
Violation invariante: reprise du travail non encore implémentée.

la solution de contournement de fournir uniquement une version 32 bits résout ce problème pour le moment

Je vois exactement les mêmes erreurs que @nadavmos sur Galaxy S7 exécutant Android 7.0. L'application plante au démarrage

Je vois exactement les mêmes erreurs que @nadavmos sur Galaxy S7 exécutant Android 7.0. L'application plante au démarrage

@nsantacruz utilisez -vous également

@nadavmos , je n'utilise pas react-navigation . C'est peut-être le même problème que # 24260 car ce problème affecte également 0.59 avec Samsung S7 sur Android 7.0

@nadavmos Le crash n'est pas lié à react-navigation , en fait l'application plante sur un nouveau projet RN créé via un init natif de réaction.

@hramos @mkonicek À partir de maintenant, nous pouvons conclure que cela semble être un problème avec la dernière version RN 0.59, affectant les versions Android fonctionnant sur Samsung S7 , S7 Edge après avoir fourni le support pour arm64-v8a , x86_64 , les supprimer de build.gradle ne plante pas l'application, ce qui pourrait potentiellement affecter la mise en ligne des applications après 1 August 2019 , conformément à la politique de support de Google Play 64 bits. Nous aimerions que vous attiriez votre attention là-dessus, s'il vous plaît?

Se passe également sur 0.58.5. Galaxy S7. Android 6.0. Le définir sur une version 32 bits ne fonctionne pas non plus.

Nous observons les mêmes plantages sur les versions 64 bits de RN 0.59.4 sur un Galaxy S7 exécutant Android 7.0. Malheureusement, nous n'avons pas accès à ce modèle d'appareil. Cela fonctionne bien sur tous les nôtres.

Avoir le même problème avec l'appareil Huawai P9 dans l'environnement suivant:

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

Voici la trace de pile Crashlytics que nous obtenons:

# 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 protected]    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 protected]              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 protected]    0x749d1865 (Missing)
45 (Missing)                              0x12c2fa8e (Missing)
46 system@[email protected]    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 protected]    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 protected]              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 protected]    0x749d1865 (Missing)
45 (Missing)                              0x12c2fa8e (Missing)
46 system@[email protected]    0x741f0347 (Missing)
47 (Missing)                              0x70d3b9ca (Missing)
48 (Missing)                              0x12c2fa8e (Missing)
49 (Missing)                              0x12c2fa8e (Missing)
50 (Missing)                              0x70abe4f6 (Missing)
51 (Missing)                              0x70aadb2e (Missing)

Avoir le même problème avec Samsung Galaxy S7, sur Android 7

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

~ L'ajout de ceci à votre android/app/build.gradle ~ peut le réparer ~ (Ce n'est pas le cas): ~

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

~ Voir https://github.com/react-native-community/jsc-android-buildscripts/pull/95~

Merci d'avoir essayé d'aider mais la solution ne nous a pas aidés.

16 апр. 2019 г., à 19:12, Andrew Jack [email protected] написал (а):

L'ajout de ceci à votre android / app / build.gradle peut le résoudre:

packagingOptions {
pickFirst ' /libjsc.so'pickFirst ' /libc++_shared.so'
}
Voir react-native-community / jsc-android-buildscripts # 95 https://github.com/react-native-community/jsc-android-buildscripts/pull/95
Tester ceci maintenant.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/facebook/react-native/issues/24261#issuecomment-483728028 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/ AEO_1BMzddSncn2DtQeDcx_y1KIz0ZSGks5vhfaJgaJpZM4cX_xB .

L'ajout de ceci à votre android/app/build.gradle peut résoudre le problème:

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

Voir react-native-community / jsc-android-buildscripts # 95

Je teste ça maintenant.

@AndrewJack fonctionnait-il pour vous?

L'ajout de ceci à votre android/app/build.gradle peut résoudre le problème:

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

Voir react-native-community / jsc-android-buildscripts # 95

Je teste ça maintenant.

Malheureusement, nous en avions déjà là-dedans.

Nous avons extrait nos versions 64 bits du Play Store. Cela n'est peut-être pas du tout lié au crash de la version 64 bits, mais les appareils Galaxy S7 exécutant la version armeabi-v7a plantent maintenant beaucoup, comme indiqué ci-dessous. Immédiatement au démarrage.

Je me demande vraiment ce qui est si différent du S7 par rapport aux autres appareils.

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)

@taschik Cela n'a pas fonctionné, j'ai pensé que la correction de la configuration de jsc-android-buildscripts pourrait fonctionner.

J'obtiens la même exception et elle ne peut pas être interceptée par le gestionnaire d'exceptions non intercepté. Dans mon application Android, j'ai essayé ce code:

Thread.setDefaultUncaughtExceptionHandler(...);

avec le gestionnaire, qui écrit uniquement le nom de l'exception dans la console, puis renvoie le contrôle au gestionnaire par défaut, mais ce code n'avait pas été exécuté avant le crash de l'application.

J'essayais d'enquêter sur les raisons pour lesquelles Crashlytics n'enregistre pas ces exceptions. C'est peut-être la raison ... Je me souviens qu'une ou deux fois j'ai vu des plantages natifs dans ma console Fabric, donc Crashlytics est capable de consigner les plantages natifs, mais d'une manière ou d'une autre pas dans ce cas.

@SpertsyanKM Le crash se produit au niveau ndk. Vous ne verrez pas le plantage dans la console Firebase, sauf si vous ajoutez la bibliothèque Crashlytics NDK. https://docs.fabric.io/android/crashlytics/ndk.html

Comme vous l'avez trouvé, Thread.setDefaultUncaughtExceptionHandler n'attrapera que les exceptions Java.

Je suis passé à RN 0.59.5 aujourd'hui et l'accident se produit toujours. Ce problème n'est pas encore résolu.

Salut à tous, j'ai le même problème dans 0.59.5, supprimez android: screenOrientation = "portrait" dans AndroidManifest.xml. Ça marche pour moi.

@Jeijie Je n'avais déjà pas ça dedans, mais ça s'est quand même écrasé.

même problème sur REDMI NOTE 4X Android 7.0 et huawei HRY AL00A Android 9

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

Même problème sur Galaxy S7 Edge / Android 7.0 et avec trois versions différentes de React-Native: 0.58.4, 0.58.5 et 0.59.5.
Le crash n'a pas été détecté sur les autres appareils Android.

La seule solution pour éviter ce problème actuellement est de créer l'application uniquement sur 32 bits. Mais le problème doit être résolu pour le premier août car le Play Store n'acceptera plus que les applications 32 bits.

Vivre la même chose, confiné au Galaxy S7 avec Android <= 7.0 (pas 8.0). Cela se produit depuis que nous avons activé le support 64 bits.

À partir de notre configuration par défaut gradle, nous ne prenons même pas en charge le 64 bits et les plantages se produisent néanmoins.
''
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 
}```

Encore un ici, j'ai remarqué que le problème se produit également avec certains appareils Mediatek
Alcatel A5 (ELSA6)
Alcatel 1x / TCL L9 (U5A_PLUS_4G)
Quelques autres appareils avec SoC MediaTek avec prise en charge x64

Salut. Nous avons constaté que:

1. ~ Le correctif pour supprimer le support 64 bits fonctionne ~ Cela n'a résolu le problème que pour certains de nos utilisateurs
2. ~ Nous avons demandé aux utilisateurs de résoudre ce problème eux-mêmes en _rémarrant leur téléphone_ (pas besoin de passer à une application 32 bits) ~ Ils n'avaient pas le même problème.

Je peux confirmer que la suppression du support 64 bits a réduit les rapports de plantage d'environ 90%
Cela se produit encore avec certains appareils. Mais le "correctif" actuel est le mieux que je puisse faire pour le moment

Je reçois également des plantages sur OnePlus 3, mais la suppression du support 64 bits n'aide pas. Je reçois des plantages avec un projet d'init natif propre (également sur les émulateurs lors de l'ouverture de l'APK de l'application).

même problème s7 edge android 7.0 plantant en production avec la division du bundle, d'autres semblent être ok
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
retour arrière:
# 00 pc 000000000009e144
# 01 pc 00000000000a4a70

Ce problème est déjà identifié sur le référentiel webkit. J'y ai commenté quand j'ai découvert ce problème il y a des mois: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/327#issuecomment -436781890

Ce serait formidable de coordonner les efforts.

Remarque: chez Youi, nous utilisons RN de manière non standard. Nous construisons notre propre JSC 64 bits, donc nous avons eu ce problème bien plus tôt, avant la 0.58.

Les facteurs communs semblent être les appareils Android 6.0 ou 7.0 (niveaux 23 et 24) et ARM 64.
L'appareil le plus courant avec cette combinaison est le S7. La mise à niveau d'un S7 vers Android 8 résout le problème.

J'ai reproduit le crash dans un émulateur Android ARM 64 bits, mais les images de l'émulateur Android ARM sont trop instables et boguées pour fonctionner. J'ai également un S7 à déboguer, que j'essaie de rétrograder vers Android 7, bien que Samsung n'ait pas rendu cela facile.

@kmagiera & @kudo vous avez récemment publié une nouvelle version de JSC. Attendez-vous que cette version corrige ce problème? Est-ce que l'alignement des versions de NDK aiderait? https://github.com/react-native-community/jsc-android-buildscripts/pull/95

@AndrewJack La nouvelle version uniquement pour les correctifs de sécurité WebKit et la suppression de libc ++ _ shared.so pour https://github.com/facebook/react-native/pull/24672. Je ne pense pas que cela résoudra les problèmes de crash.

AFAIK, il existe différents types de crash JSC.
Certains proviennent de operationLinkDirectCall comme ce problème l'a signalé et d'autres sont NPE sous le nom https://github.com/react-native-community/jsc-android-buildscripts/issues/84.
La plupart d'entre eux sont liés à JIT.
Le chemin du crash JIT est difficile à reproduire en interne et à dépanner également.
J'ai quelques correctifs potentiels mais je ne sais pas si ceux-ci résoudront vraiment le problème du crash.

• L'un des correctifs consiste à désactiver DFG_JIT .

• Il existe également un correctif de l'opération liée en amont.

• Le nouveau JSC (WebKitGTK 2.24) inclut de nombreux changements JIT. Cela vaut la peine d'essayer si la mise à niveau aide.

OMI, si la reproduction en interne n'est pas possible, une alternative est de livrer une construction expérimentée.

Mon plan est de faciliter la mise à niveau de JSC, simplement yarn add jsc-android@experiment . Cela devrait se produire au RN 0.60.
Avec ce mécanisme, nous pourrions au moins avoir une longueur d'avance pour résoudre les problèmes de crash.

D'un autre côté, il serait utile d'avoir un code et un environnement de reproduction fiables.
Par exemple, il existe un dépôt de react-native-navigation. Cela aide beaucoup.
https://github.com/react-native-community/jsc-android-buildscripts/issues/84#issue -407898908

Le crash se produit également sur Pixel 2 avec Android 9, si cela aide.
Existe-t-il un moyen d'obtenir des journaux d'incidents lors de l'exécution d'APK? Je serai ravi de vous aider à obtenir plus d'informations sur ces plantages, mais je ne sais pas grand-chose sur le développement Android.

@quietbits , la plupart des journaux liés à ces problèmes ne sont pas très utiles, mais pour les sortir:

Cherchez quand le crash se produit en utilisant adb logcat cela ressemblera à quelque chose comme ça (pas exactement, puisque je viens de l'extraire du haut du journal, mais il montre un extrait, c'est pourquoi je le pointe en dehors):

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

Il dira aussi généralement que le journal est écrit sur une «pierre tombale».

Pour obtenir la pierre tombale, utilisez adb bugreport ./MySuperSpecialBugReport la dernière partie étant évidemment le chemin dans lequel vous le souhaitez.

Il sera retiré sous forme de zip, et vous pourrez le décompresser, naviguer (sur la plupart des appareils) vers: ./MySuperSpecialBugReport/FS/data/tombstones et vous pourrez ensuite ouvrir la pierre tombale avec votre éditeur de texte.

Encore une fois, étant donné la nature de ces accidents, ils ne sont pas très informatifs. Au moins avec les nôtres, ils sont généralement avec mqt_js, et à une adresse de pointeur faible. Ils se produisent également (bien que de moins en moins bizarres / imprévisibles) avec des apks 32 bits uniquement.

===

@ Kudo - j'ai vraiment hâte de pouvoir essayer différents JSC plus facilement et de voir ce qu'ils font. Jusqu'à présent, cela a été un véritable problème lors de la mise à niveau vers 0,59 avec des plantages super non déterministes et imprévisibles (qui ne se produisent également que sur certains appareils ... parfois).

Pour obtenir la trace symbolique, j'avais l'habitude de combiner adb logcat et ndk-stack
Par exemple, cibler le stock JSC RN 059 (qui est [email protected]) et 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

Une mise à jour sur ce problème?

La suppression de 64 bits n'est pas une solution selon Google Play 64 bit support policy. Cela pourrait potentiellement affecter la mise en ligne des applications après 1 August 2019 . Nous aimerions avoir une solution appropriée pour ce problème. @hramos une mise à jour à ce sujet? Veuillez attirer l'attention.

Salut à tous, j'ai le même problème en 0.59.8,
Nous aimerions avoir une solution appropriée pour ce problème.

Salut,
J'aide avec le problème de crash JSC et aussi un collaborateur de jsc-android-buildscripts.
RN 0.59 JSC est en fait issu de jsc-android-buildscripts .

Pour résoudre le problème de plantage, nous avons besoin du retour en arrière du crash.
Avec un peu de chance, veuillez suivre les étapes ci-dessous pour obtenir un retour en arrière et publier ici.
Je pourrais ensuite faire un suivi pour trouver des solutions potentielles.

Installez ndk-build et exécutez les commandes:

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

Il semble que beaucoup de crashs proviennent du Samsung S7. Malheureusement, je n'ai pas de S7 sous la main.
J'espère obtenir des informations utiles pour aller plus loin dans le dépannage.

@marlonchalegre

@Kudo C'est le journal que j'ai obtenu en exécutant ces commandes sur un nouveau projet sur RN 0.59.8
J'ai essayé de créer des versions de débogage et de publication et la compilation du jsc moi-même par les journaux était la même dans chaque cas.

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

J'ai un S7 à portée de main et je serais heureux d'essayer de lancer autre chose pour essayer de comprendre cela.

Ma suggestion est de recompiler le JSC avec JIT désactivé . Il est possible que les mécanismes de sécurité du système d'exploitation interfèrent avec les JIT
opérations d’une manière imprévisible.

J'ai reproduit les mêmes journaux de crash que @MalcolmScruggs. Sur un S7 - Android 7.1.2 - LineageOS 14.1.

Sur RN 0.59.8 et la dernière version de la branche principale .

Aucune modification requise pour reproduire le crash. Le modèle RN par défaut déclenche un crash après avoir tapoté un peu sur l'écran.

Repo ici - https://github.com/AndrewJack/jsc_crash/tree/rn_master_branch
Les journaux de panne se trouvent dans le

Étapes suivantes: créer sa propre version de JSC avec JIT désactivé

Si quelqu'un a un S7 sur une version plus récente d'Android et qu'il souhaite rétrograder. C'est ce que j'ai fait:

Téléchargez ce logiciel:

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

1. Installer la récupération TWRP (en utilisant odin [nécessite Windows] ou une autre méthode)
2. Démarrer la récupération
3. stockage de montage
4. copier le package rom et gapps LineageOS
5. installer des images Flash LineageOS et gapps
6. redémarrer.

Avec le dernier maître natif de réaction et en utilisant no_dfg_jit ou no-jit de la fourche de

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

@AndrewJack Incroyable, vous avez trouvé mes builds expérimentés si rapides.
Merci pour vos commentaires et bon de savoir que ces versions ont corrigé le crash pour vous.

Mes chers,

J'ai eu deux versions de JSC expérimentées, veuillez essayer si elles peuvent résoudre les plantages pour vous.
Quelques étapes ici:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Une version expérimentée consiste à désactiver un type de JIT.
Et l'autre désactive totalement JIT de @matthargett recommandé.
Si les deux versions résoudront le crash pour vous, veuillez également nous faire part de vos performances globales et du TTI comme mentionné dans mon essence.

@Kudo Merci pour ceux-là! Que savez-vous de la GC simultanée dans ces versions? J'ai vu mentionné quelque part que c'était une autre différence par rapport à la version 32 bits, mais bien sûr, je ne trouve plus ce commentaire. Peut-être vaut-il la peine de jouer avec les pannes en cas de persistance.

@wbercx Voulez-vous dire GC simultané ou JS concurrent (JIT simultané)?
Par défaut, le GC simultané n'est activé que pour arm64 et x64.
Concurrent GC peut ne pas être lié au problème de plantage. Il s'agit probablement de la gestion du tas et non de JIT.

Le JS simultané est désactivé pour mes deux versions.
(Par défaut, il ne sera activé que pour ENABLE(DFG_JIT) && USE(JSVALUE64) )

BTW, JIT dans JavaScriptCore est compliqué et je ne suis pas un expert en la matière.
N'hésitez pas à signaler si je me suis trompé.

@Kudo J'ai essayé vos versions JSC expérimentales no-jit et no-dfg-jit et je n'ai pas pu reproduire le crash. Cela semble être conforme à ce que @AndrewJack a rapporté.

J'essayais cela sur un projet de base, je ne peux donc pas commenter l'impact sur les performances.

J'ai quelques informations supplémentaires, je vois aussi ce crash sur:
Samsung Galaxy S7 (herolte), Android 7.0
Oppo F7 (CPH1819), Android 8.1

Se passe également sur 0.58.5. Galaxy S7. Android 6.0. Le définir sur une version 32 bits ne fonctionne pas non plus.

Le crash se produit toujours ici aussi après le retour à 32 bits

@MalcolmScruggs C'est bien d'entendre les deux versions expérimentées résoudre le crash pour vous.
Je pense désactiver DFG_JIT, au moins l'option JIT est alignée sur l'ancien JSC.

@Kudo Vous prévoyez de cibler votre solution de désactivation de DFG_JIT uniquement sur les périphériques / processeurs concernés?

Quelqu'un a-t-il essayé avec la dernière version de React Native (0.59.8) qui corrige quelques plantages (mentionnés dans la note de publication)?
https://github.com/facebook/react-native/releases

Quelqu'un a-t-il essayé avec la dernière version de React Native (0.59.8) qui corrige quelques plantages (mentionnés dans la note de publication)?
https://github.com/facebook/react-native/releases

Dans mon cas, j'utilisais 0.59.8, je suis depuis revenu à 0.57.8 car rien d'autre ne semblait fonctionner. Ce bogue est particulièrement grave car il provoque le blocage de l'application immédiatement à l'ouverture. Mon application a été coupée dans les critiques.

Ces appareils ont un crash de signal 11 mais il montre juste un emplacement mémoire.

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

Ces périphériques semblent apparaître avec une erreur qui ressemble à == / lib / arm64 / libjsc.so . Je ne connais pas assez le fonctionnement interne pour savoir ce que cela signifie, mais j'espère que cela aide.

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

Je peux ajouter quelques appareils à la liste de @ harryt2.

Crash du signal 11 avec seulement un emplacement mémoire:

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
...
La liste se poursuit avec ~ 65 appareils différents et la version Android entre 7.0 et 9.0.

L'erreur ne se produit pas toujours sur ces appareils. Mais c'est une réelle préoccupation, puisque le taux de plantage de mon application rapporté dans google play est passé de 0,16% à 1,02% après la mise à jour de 0,57,8 à 0,59,5.

0,57,8:

0,59,5:

Je ne suis pas un expert en développement Android, et je ne comprends pas non plus d'où vient ce crash. Je peux fournir quelques données supplémentaires si cela peut aider.

@ntorion sur notre projet, nous voyons toujours ces plantages sur Samsung s7 avec react-native 0.59.8 j'ai peur.

Une solution pour cela en ce moment?
J'ai testé dans deux Galaxy Note 9 différents, chaque téléphone plante immédiatement

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

@dudusotero utilise l'instruction @Kudo https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

@matpaul @Kudo je peux confirmer que cette version expérimentale de js core semble également résoudre le problème pour nous (testé sur Samsung s7).

Mes plantages liés à cette trace ont disparu sur Android lorsque je suis passé à 0.58.6 . Je prévoyais de devoir passer à 57.6 , mais 58.6 semble avoir résolu ce problème pour moi (bien qu'il y ait d'

@Kudo

Mes chers,

J'ai eu deux versions de JSC expérimentées, veuillez essayer si elles peuvent résoudre les plantages pour vous.
Quelques étapes ici:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Une version expérimentée consiste à désactiver un type de JIT.
Et l'autre désactive totalement JIT de @matthargett recommandé.
Si les deux versions résoudront le crash pour vous, veuillez également nous faire part de vos performances globales et du TTI comme mentionné dans mon essence.

@Kudo J'ai eu deux observations ici, comme également mentionné dans votre résumé

• L'application se bloque avec @kudo-ci/jsc-android@241213-no-dfg-jit dépendance
• L'application fonctionne bien avec la dépendance @kudo-ci/jsc-android@241213-no-jit as of now et TTI reste le même / imperceptible par rapport aux versions précédentes.

Bravo, votre pull request sera-t-il suffisant pour résoudre ce problème, car j'ai remarqué le blocage de l'application lors du test contre no_dfg_jit

Quelques mises à jour supplémentaires ici:
Je doute vraiment que le crash natif se produise facilement sur S7 edge, il devrait y avoir d'autres applications confrontées à de tels problèmes.
Je t'ai eu!
Le service Google Play avec l'API Text a rencontré ce problème, mais aucun correctif OSS
Mono a trouvé un problème de plantage sur l'arc bit.LITTLE de S7 Exynos et voici le correctif .

JavaScriptCore a utilisé __clear_cache dans ARM64Assembler.
J'aurai une autre version expérimentée pour patcher __clear_cache plus tard cette semaine.

Les builds expérimentés qui ont corrigé __clear_cache sont prêts.

Les étapes sont les mêmes que précédemment, mais uniquement pour utiliser une dépendance npm différente.

1. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-dfg' et logcat adb confirmé avec la version 241213.8000.0 ( ref code source ici )
2. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg' et logcat adb confirmé avec la version 241213.9000.1 ( ref code source ici )

Je suis désolé de ne pas pouvoir vérifier à nouveau le problème de plantage, mais uniquement pour vérifier les fonctionnalités de base.
S'il vous plaît aider à tester les deux expériences JSC si possible.
Merci beaucoup et nous souhaitons bonne chance cette fois.

cc @AndrewJack @MalcolmScruggs @tijs @ishantsagar @timhatch

@Kudo J'ai maintenant eu des commentaires sur les versions de test utilisant à la fois @kudo-ci/jsc-android@241213-fix-clear-cache-dfg et @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg .
Les deux versions de test semblent être sans crash jusqu'à présent sur le Samsung Galaxy S7 Edge / Android 7.0 (jusqu'à présent, la combinaison de problèmes)

@Kudo J'ai essayé à la fois @kudo-ci/jsc-android@241213-fix-clear-cache-dfg et @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg sur un projet de base exécutant React-Native 0.59.8 et sur les deux versions le crash ne se produit pas. J'ai testé sur un Samsung Galaxy S7 sous 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 J'ai essayé le dernier @kudo-ci/jsc-android@241213-fix-clear-cache-dfg mais j'ai rencontré un crash sur un Samsung Galaxy S5 (SM-G900F), similaire à celui que nous avons eu avec le JSC dans React Native 0.59.8

La version sans JIT fonctionnait parfaitement ( @kudo-ci/jsc-android@241213-no-jit ) et n'a rencontré aucun crash sur celle-ci, peu importe à quel point j'ai poussé l'application à ses limites. Je pense donc que nous allons nous en tenir à celui-là pour le moment.

Nous utilisons ReactRootViews dans un viewpager, donc nous créons et détruisons assez souvent des instances natives de réaction, et cela semble déclencher ce crash. C'est probablement pourquoi nous rencontrons ce problème plus souvent que la plupart des autres. Nous revoyons l'approche viewpager pour le moment, mais en attendant, j'espère que ce journal des plantages pourra être utile. (c'est pour la version 241213.8000.0 , react-native 0.59.8)

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

Malheureusement, nous en avions déjà là-dedans.

Nous avons extrait nos versions 64 bits du Play Store. Cela n'est peut-être pas du tout lié au crash de la version 64 bits, mais les appareils Galaxy S7 exécutant la version armeabi-v7a plantent maintenant beaucoup, comme indiqué ci-dessous. Immédiatement au démarrage.

Je me demande vraiment ce qui est si différent du S7 par rapport aux autres appareils.

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)

Nous avons vu cela en interne et avons remarqué que certaines de nos propriétés de style renvoyaient conditionnellement null. La suppression de cela et l'ajout conditionnel de la propriété style ont corrigé une exception similaire - il se peut qu'il se passe quelque chose avec un type de module natif pour le vôtre?

@tuncaulubilge Merci pour l'information.
Juste pour confirmer que le Samsung S5 (SM-G900F) est une architecture arm (pas arm64), non?
Vous pouvez vérifier par adb shell getprop ro.product.cpu.abi
D'après votre journal de crash, il semble que ce soit arm.

Si tel est le cas, je suppose que la cause profonde devrait être encore une autre histoire qu'ici.
Avez-vous déjà testé la version no-dfg-jit, c'est- @kudo-ci/jsc-android@241213-no-dfg-jit dire @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg ?
Ces deux versions doivent être identiques sur arm32, vous pouvez simplement tester l'une ou l'autre.

MISE À JOUR

Le retour en arrière signalé via la console du développeur pour le problème d'origine (plantages répétables au lancement de l'application sur [exclusivement] Samsung S7 Edge + Android 7.0) ressemble à ceci:

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

Le problème d'origine semble être résolu par chacune des versions suivantes:
@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

J'ai cependant réussi à stimuler un autre crash à deux reprises pour le dernier de ceux-ci ( @kudo-ci/jsc-android@241213-fix-clear-cache-dfg ) sur un appareil différent et avec une trace différente:

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

Bien que j'aie réussi à planter l'application de test deux fois, à chaque fois avec la même signature, le crash n'est pas systématiquement répétable et se produit lors de la navigation entre différents écrans dans l'application de test et non au lancement. Comme l'appareil concerné est à portée de main, j'ai pu extraire une trace plus complète de l'appareil qui se lit comme suit:

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

et

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

Je ne sais pas si cela aide, le débogage et l'interprétation des plantages sur Android ne sont pas quelque chose que j'ai fait auparavant

@Kudo Voici mes conclusions:

Le Samsung S5 est armeabi-v7a . J'ai essayé les 4 alternatives que vous avez fournies, et celle sans jit semble être la seule sans plantage. La désactivation de dfg réduit beaucoup le taux de crash mais je pourrais toujours le planter.

Je teste également sur un Pixel XL ( arm64-v8a ) et je n'ai pas encore rencontré de plantages sur kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg mais le crash est difficile à reproduire sur un appareil haut de gamme car la cause principale semble être une faible pression de la mémoire.

Pour résumer:
@kudo-ci/jsc-android@241213-no-jit : c'est sans plantage sur les deux appareils
@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg : Cela plante sur les appareils bas de gamme, ne peut pas se reproduire sur les appareils haut de gamme
@kudo-ci/jsc-android@241213-fix-clear-cache-dfg : Cela plante plus fréquemment que l'autre build sur un appareil bas de gamme. (toujours mieux que le stock RN 59 jsc)
@kudo-ci/jsc-android@241213-no-dfg-jit : Cela a également planté sur les appareils bas de gamme, je n'ai pas testé sur un haut de gamme.

Même la construction sans jit est considérablement plus rapide que les JSC stock, nous prévoyons donc d'utiliser @kudo-ci/jsc-android@241213-no-jit et nous allons le tester davantage pour nous assurer qu'il est prêt pour la production.

Merci beaucoup pour toute l'aide au fait. Faites-moi savoir si je pourrais être utile

@timhatch @tuncaulubilge Merci pour vos impressionnants tests et commentaires systématiques.
À l'heure actuelle, je n'ai vraiment aucune idée de résoudre le problème.
Ni désactiver DFG ni réparer __clear_cache n'aide à cela.
De plus, le crash se produit également sur arm32 (et la cause première peut être différente de arm64)

À mon avis, je voudrais désactiver le JIT par défaut, au moins pour m'assurer que nous avons d'abord un JSC sans crash.
BTW @tuncaulubilge comment avez-vous mesuré que @kudo-ci/jsc-android@241213-no-jit est plus rapide que le stock JSC?
Juste curieux puisque d'après le résultat de référence, la version no-jit agit un peu plus lentement.

@Kudo Avez-vous également mesuré le temps de démarrage de l'application et l'utilisation de la mémoire? J'ai toujours supposé que ces deux métriques seraient meilleures sans JIT. Étant donné que la plupart des applications sont lourdes d'interface utilisateur, je ne suis pas sûr que JIT sera d'un grand avantage dans les applications du monde réel, j'aimerais donc que JIT soit désactivé si cela améliore le démarrage et l'utilisation de la mémoire. Je suis également curieux de savoir si JSC aura une empreinte de disque plus petite sans JIT.

@Kudo
Corriger __clear_cache comme vous l'avez fait dans ces versions de test améliore certainement la situation, mais soit il y a un effet secondaire du correctif, soit une interaction plus complexe qui n'est pas encore évidente. Cela dit, je n'ai pas pu à nouveau planter l'application de test -fix-clear-cache-dfg . Il se peut que, comme le dit @tuncaulubilge , le comportement dépende de la pression de la mémoire et / ou d'autres facteurs.

Désactiver complètement JIT semble être l'option "sans crash", je n'ai pas remarqué de dégradation des performances avec cette option donc ce serait le choix "sûr".

@Kudo pour clarifier, j'ai comparé React-Native 0.58.6 (sans jsc personnalisé installé) à 0.59.8 avec @kudo-ci/jsc-android@241213-no-jit .

Je n'ai fait aucune mesure mais l'amélioration des performances est très notable. Je m'attendrais à ce que la version no jit soit un peu plus lente que la version [email protected] comme vous l'avez mentionné, mais c'est ignorable en comparaison. Je suggérerais également d'utiliser la version no-jit comme option par défaut, car les améliorations de stabilité l'emportent largement sur l'amélioration mineure des performances que vous obtiendrez de jit.

Nous utilisons Expo v32 pour créer notre application et nous constatons cette erreur sur les versions et les appareils Android.

@ tido64 TTI n'a pas beaucoup de différences. La taille binaire réduit d'environ 1 Mo à partir de la version no_dfg. La mémoire réduit d'environ 48%.
J'ai envoyé un PR pour désactiver totalement JIT et il y a un résultat de mesure.
https://github.com/react-native-community/jsc-android-buildscripts/pull/108

@timhatch C'est bon d'entendre réparer __clear_cache aide un peu.
Je doute toujours que la cause première vienne de big.LITTLE, mais je n'ai pas encore trouvé d'autre code JSC causant des problèmes.
Les Samsung S5 et S7 sont grands, LITTLE et les deux processeurs ont une taille de ligne de cache différente.
C'est peut-être la raison pour laquelle je n'ai pas pu reproduire le crash sur Samsung Note 5, car la taille de la ligne de cache de ses deux processeurs est de 64B.
Je ne sais pas s'il est possible pour le planificateur de système d'exploitation et JSC de faire la transition entre un gros <-> LITTLE CPU au moment de l'exécution.
Si c'est vrai, le problème peut surtout se produire à ce moment-là.

@tuncaulubilge C'est curieux pour moi.
Vous pouvez vérifier mon PR , la version no-jit est plus lente que le stock RN058 JSC.
C'est aussi ce que j'ai ressenti lors de la mesure.
Peut-être que les points de repère sont des cas extrêmes et ne ressemblent plus à une application RN.
BTW, j'ai vu la taille binaire et la taille de la mémoire réduire par rapport à la version no-jit.
Ces deux avantages et l'absence de crash sont plus raisonnables pour moi.

Ce code sauve des vies

@RomanovYurii Lorsque nous avons supprimé les filtres ndk 64 bits "arm64-v8a", "x86_64" de ndk abiFilters dans le bloc defaultConfig de build.gradle en ne prenant en charge que 32 bits. Le plantage a disparu, mais selon le mandat de support de Google 64 bits, cela doit être corrigé avec le support ndk 64 bits.

25060

@dishantwalia @Kudo désactivé JIT fonctionne pour moi sur 64 bits et ne voit aucun problème de performance jusqu'à présent.

Cet essentiel a fonctionné pour moi https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Mes chers,

Nous avons publié le JSC no-JIT dans jsc-android npm et j'ai révisé mon essence précédente pour utiliser jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
J'espère résoudre tous les problèmes de crash.
S'il n'y a pas de baisse significative des performances, nous proposerons officiellement la version no-JIT en tant que version

Mes chers,

Nous avons publié le JSC no-JIT dans jsc-android npm et j'ai révisé mon essence précédente pour utiliser jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
J'espère résoudre tous les problèmes de crash.
S'il n'y a pas de baisse significative des performances, nous proposerons officiellement la version no-JIT en tant que version

Merci @Kudo disable-jit fonctionne pour nous comme un charme !!!

Merci @Kudo pour tout le travail acharné! 241213.2.0 semble avoir résolu les plantages pour nous. Malheureusement, l'impact sur les performances est assez important. Sur les appareils bas de gamme sur certains de nos écrans plus occupés, nous avons vu js fps diminuer de 20 à 30%.

Je peux également confirmer que les plantages ont disparu, mais nous constatons également des performances assez médiocres dans les appareils bas de gamme. Je dois dire que c'est extrêmement décevant étant donné que nous avons attendu la mise à niveau vers RN58 / RN59 pour le JSC plus moderne.

@kudo dans le pire des cas, le jit ne devrait être désactivé que pour la version 64 bits, seuls les appareils compatibles 64 bits plantent

@yenda si cette version devient le correctif, ce serait bien d'avoir cette option oui. Je ne sais pas à quel point ce serait difficile. Espérons que cela ne signifierait pas l'envoi de deux versions du JSC

@benoitdion @ItsNoHax Pouvez-vous énumérer les appareils spécifiques sur

Testé sur un Nexus 5 et une Samsung Tab E entre autres.

Pour tous les Googleurs qui mettent à niveau leur projet RN vers 59.x, assurez-vous que dans android/app/build.gradle -> android {defaultConfig {versionName}} ne correspond pas à la version spécifiée par react-native-code-push.

J'ai eu du mal environ trois jours pour le même problème et j'ai découvert plus tard que mon projet React Native mis à niveau à la v59.3 était mis à jour par code-push qui a React Native v54.7

Cela ne doit pas être le cas pour 90% de la population. Mais pour certains comme moi, cela peut gagner du temps.

Après cela, merci à @Kudo. Correction des problèmes de crash.

Huawei Honor 8X a aussi ce problème

Je peux également confirmer que les plantages ont disparu, mais nous constatons également des performances assez médiocres dans les appareils bas de gamme. Je dois dire que c'est extrêmement décevant étant donné que nous avons attendu la mise à niveau vers RN58 / RN59 pour le JSC plus moderne.

Pareil ici. L'ancien RN sur Android était lent et crash, le nouveau RN est rapide et crash et avec ce correctif, le nouveau RN est stable et lent. Il semble que nous ne pouvons pas tout avoir sur Android. 🙈

Mes chers,

Je suis désolé que la performance ait mal agi pour la version no-JIT.
Et désolé je n'ai pas de solutions pour le moment.
Il m'est difficile de résoudre un tel problème que je n'ai pas pu reproduire.
J'espère que quelqu'un de la communauté pourra aider à creuser le problème.

JSC pour RN est OSS à https://github.com/react-native-community/jsc-android-buildscripts.
Il prend en charge l'activation de la génération de débogage en décommentant la ligne dans https://github.com/react-native-community/jsc-android-buildscripts/blob/master/scripts/start.sh#L10.
Attacher gdb ou lldb pour déboguer de manière native, peut-être y aura-t-il un indice.
Le crash peut violer certains RELEASE_ASSERT dans https://trac.webkit.org/browser/webkit/releases/WebKitGTK/webkit-2.22.6/Source/JavaScriptCore/jit/JITOperations.cpp#L1067 , mais je ne sais pas comment le problème va à l’État.

Merci pour tout votre travail à ce sujet et jsc-android-buildscripts @Kudo. Ça a été incroyable de suivre vos progrès! Y a-t-il quelque chose que nous (la communauté qui regarde ce problème) pouvons faire pour vous aider? Je crois que @tuncaulubilge avait un cas de repro presque stable.

Peut-être que l'équipe interne de Facebook React-Native a des experts JSC?

Je viens de faire face à ce problème, ne se produit que sur REAL DEVICE, LENOVO A701a48, RUNNING ANDROID 6.
suppression de "arm64-v8a", "x86_64" de

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

Je l'ai résolu mais je me suis senti un peu piraté.

J'espère que l'équipe de RN sera bientôt mise à jour :(

Mes chers,

Voici probablement ma dernière tentative: utiliser une version plus récente de WebKit.
@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg est basé sur WebKitGTK 2.24.2, avec JIT de base mais pas de DFG JIT.
Un changement notable est que WebKit plus récent a changé le format de bytecode JIT.
Le JIT de x86 n'est pas pris en charge et le support JIT d'armeabi-v7a provient de la communauté (merci Igalia).
Puisque le crash ne se produit que sur arm64, la nouvelle version vaut toujours la peine d'essayer.

Les étapes détaillées pour intégrer cette version se trouvent sur https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md.
Le changement notable est que 241213 -> 245459 de la version précédente de JSC et assurez-vous d'avoir 245459.9000.0 dans le journal adb.
Veuillez aider à vérifier ce JSC expérimenté.
J'espère que nous avons de la chance cette fois. 🤞

@benoitdion merci pour votre encouragement ❤️

@Kudo @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg fonctionne bien!

Peut confirmer que l'accident qui se produisait avec RN v0.59, en utilisant le JSC ci-dessus, a disparu. Testé dans Google Nexus 6, les autres seront confirmés après le déploiement.

Merci!!

@Kudo Je peux confirmer que @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg fonctionne aussi pour moi. Aucun crash ne se produit dans le Samsung Galaxy S7 SM-G930FD qui se produisait auparavant avec RN v0.59 et a été corrigé avec no-jit ou jsc-android v241213.2.0 .

Je n'ai pas encore eu la chance d'intégrer cette nouvelle version car j'ai d'autres jalons de projet qui me gênent, mais je prévois de le faire dès qu'ils ne seront plus sur le chemin.

Les builds originaux no-dfg @Kudo ont corrigé 99% des plantages que j'avais vus et même si j'étais capable de stimuler un seul crash, je n'ai pas pu le répéter.

Je crois que @tuncaulubilge a pu reproduire les plantages avec les builds originaux no-dfg , donc il serait intéressant de voir ce qu'il fait de cette nouvelle build.

@rimzici @dishantwalia @timhatch Merci pour votre aide.

@tuncaulubilge Si vous avez du temps disponible, pourriez-vous s'il vous plaît aider à vérifier la dernière version expérimentée?
IIRC, seuls vous et @timhatch avez signalé des plantages de la dernière fois " 241213 -fix-clear-cache-no-dfg".
J'espère que nous pourrons corriger les plantages avec la version mise à jour.
Merci.

@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
avoir ce problème après avoir intégré @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg sur ZTE Blade, Samsung S8, OnePlus 6. Uniquement sur Motorola Z2 Android 7.1.1 a commencé la construction!

@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
avoir ce problème après avoir intégré @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg sur ZTE Blade, Samsung S8, OnePlus 6. Uniquement sur Motorola Z2 Android 7.1.1 a commencé la construction!

Cela semble lié à realm s'il vous plaît vérifier https://github.com/realm/realm-js/issues/2261#issuecomment -468691502
https://github.com/realm/realm-js/issues/2221

@Kudo Encore une fois, merci pour l'excellent travail! Malheureusement, je suis passé à un nouveau projet et je n'ai plus accès à l'ancien projet. Je vais essayer de rejoindre mes anciens coéquipiers et demander à quelqu'un d'essayer ça.

Nous avions des plantages en particulier sur reactRootView.unmountReactApplication , ce qui déclenche le ramassage des ordures, conduisant à des plantages occasionnels. Vous pourrez peut-être le reproduire avec un exemple d'application, en créant et en détruisant 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
avoir ce problème après avoir intégré @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg sur ZTE Blade, Samsung S8, OnePlus 6. Uniquement sur Motorola Z2 Android 7.1.1 a commencé la construction!

Cela semble lié à realm veuillez vérifier realm / realm-js # 2261 (commentaire)
royaume / royaume-js # 2221

Merci beaucoup! Juste dû mettre à jour le royaume à 2.28.
@Kudo merci spécial. Mon application fonctionne déjà correctement!

@Kudo J'ai reconstruit une version d'une application précédemment affectée avec la même configuration de construction que dans les tests précédents mais en utilisant @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .
Pas de plantages ni de blocages jusqu'à présent - je vais voir si je peux stresser l'application tout au long du week-end et faire un rapport si je rencontre des problèmes.

@timhatch Merci beaucoup et prenez votre temps pendant le week-end.
Croiser les doigts pour entendre de bonnes nouvelles de votre part la prochaine fois.

Je ne peux pas construire avec le patch. J'obtiens l'erreur suivante du FBSDK:

`` ``
Tâche: react -
/ Utilisateurs / waltermonecke / Documents / Code / React-Native2 / moodPixel / node_modules / react-native-fbsdk / android / src / main / java / com / facebook / reactnative / androidsdk / FBAppEventsLoggerMod
ule. java: 209 : erreur: symbole introuvable
@ReactMethod (isBlockingSynchronousMethod = true)
^
symbole: méthode isBlockingSynchronousMethod ()
Lieu: @interface ReactMethod
Remarque: certains fichiers d'entrée utilisent ou remplacent une API obsolète.
Remarque: Recompilez avec - Xlint: obsolescence pour plus de détails.
Remarque: /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java utilise des opérations non vérifiées ou non sécurisées.
Remarque: Recompiler avec - Xlint: décoché pour plus de détails.
1 erreur

ÉCHEC: la construction a échoué avec une exception.
`` ``

@wmonecke Le problème me semble étrange. Je n'ai touché à aucun code java ou dépendances de gradle dans JSC AAR.
Pourriez-vous vérifier le problème ou décrire brièvement comment vous appliquez le correctif?
Je suppose que vous utilisez accidentellement une ancienne dépendance RN et
vous pouvez vérifier par ./gradlew :app:dependencies | grep 'com.facebook.react:react-native:' (veuillez vous assurer que la version RN renvoyée est celle que vous attendiez).

Je ne peux pas construire avec le patch. J'obtiens l'erreur suivante du 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: <strong i="7">@interface</strong> 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 vous devez ajouter les deux
maven {
// Tous les React Native (JS, sources Obj-C, binaires Android) sont installés à partir de npm
url "$ rootDir /../ node_modules / react-native / android"
}

maven {
// Repo Maven local contenant des AAR avec bibliothèque JSC conçue pour Android
url "$ rootDir /../ node_modules / @ kudo-ci / jsc-android / dist"
}

@Kudo Aucun problème avec @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Aucune application ne se bloque ou ne plante.

@Kudo Aucun problème avec @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Aucune application ne se bloque ou ne plante.

@Kudo Veuillez pousser ce correctif dans jsc-android-buildscripts et publier une version. Nous pouvons donc le déployer dans nos applications de production https://github.com/react-native-community/jsc-android-buildscripts.

@timhatch Génial! Particulièrement merci pour votre verficiation. Poussera bientôt les changements JSC en RN.

@dishantwalia Oui, en cours. Merci.

Merci @Kudo pour tout votre travail à ce sujet. Pouvez-vous (ou quelqu'un d'autre qui sait ce qui se passe) s'il vous plaît me guider dans la bonne direction pour mettre en œuvre ce correctif (je me rends compte que c'est un travail en cours).

Je suis actuellement sur RN 0.59.9. Avec les changements en cours de déploiement, une version mise à jour de RN deviendra-t-elle disponible quelque chose comme 0.59.10 ou devrais-je plutôt installer jsc-android-buildscripts tant que package tiers et implémenter pour 0,59x selon la documentation?

@Kudo Aucun problème non plus avec votre dernière version. Bon travail! 💪

Merci @Kudo , j'ai la même question que @jacquesdev pose 0.59.10 ou jsc-android-buildscripts ?

@Kudo @dishantwalia
Merci! Je gardais seulement:
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" }

avec build.gradle

@Kudo malheureusement le problème est toujours là (Galaxy S7, Android7). J'ai essayé @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .

J'ai également essayé la version no-JIT, qui n'a pas aidé. Je n'ai pas réussi à faire en sorte que la version "JavaScriptCore" soit imprimée dans adb logcat en utilisant le grep que vous avez fourni, je n'ai pas non plus vu aucune mention de JavaScriptCore dans le journal lui-même en recherchant manuellement.

Je peux reproduire le crash assez fréquemment. Il ne plante pas toujours au même endroit.

Voici l'erreur (245459-fix-clear-cache-no-dfg):

06-26 13:56:22.982  4374  4521 W google-breakpad: Chrome build fingerprint:
06-26 13:56:22.982  4374  4521 W google-breakpad: 3.0.70
06-26 13:56:22.982  4374  4521 W google-breakpad: 30070
06-26 13:56:22.982  4374  4521 W google-breakpad: ### ### ### ### ### ### ### ### ### ### ### ### ###
06-26 13:56:22.984  4374  4521 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xafca in tid 4521 (mqt_js)
06-26 13:56:22.986  3075  3075 W         : debuggerd: handling request: pid=4374 uid=10169 gid=10169 tid=4521
06-26 13:56:23.089  3769  5715 D SSRM:k  : SIOP:: AP = 430, PST = 398 (W:6), CP = 318, CUR = -104, LCD = 99
06-26 13:56:23.154  4557  4557 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-26 13:56:23.156  4557  4557 F DEBUG   : Build fingerprint: 'samsung/hero2ltexx/hero2lte:7.0/NRD90M/G935FXXU1ZPL3:user/release-keys'
06-26 13:56:23.156  4557  4557 F DEBUG   : Revision: '8'
06-26 13:56:23.156  4557  4557 F DEBUG   : ABI: 'arm64'
06-26 13:56:23.157  4557  4557 F DEBUG   : pid: 4374, tid: 4521, name: mqt_js  >>> com.myapp <<<
06-26 13:56:23.157  4557  4557 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xafca
06-26 13:56:23.157  4557  4557 F DEBUG   :     x0   000000000000a01a  x1   0000000000000000  x2   00000079f6a30000  x3   0000007a05afe748
06-26 13:56:23.157  4557  4557 F DEBUG   :     x4   0000000000000000  x5   0000000000000010  x6   ffff000000000002  x7   0000000000009ab0
06-26 13:56:23.158  4557  4557 F DEBUG   :     x8   0000007a045acd6c  x9   0000000000000002  x10  0000000000000001  x11  0000000000000000
06-26 13:56:23.158  4557  4557 F DEBUG   :     x12  0000000000000fff  x13  00000079df7ed2b8  x14  00000079f6973890  x15  0000000000000001
06-26 13:56:23.158  4557  4557 F DEBUG   :     x16  00000079f6a59a30  x17  0000007a1ae56058  x18  000000000045b4fb  x19  0000007a05afe7f0
06-26 13:56:23.158  4557  4557 F DEBUG   :     x20  0000007a05afe750  x21  00000079f6a3a6b8  x22  0000007a1ae4b000  x23  00000079f693cf50
06-26 13:56:23.158  4557  4557 F DEBUG   :     x24  0000000000000000  x25  00000079df415e10  x26  0000000000000001  x27  ffff000000000000
06-26 13:56:23.158  4557  4557 F DEBUG   :     x28  ffff000000000002  x29  0000007a05afe750  x30  0000007a045ac890
06-26 13:56:23.158  4557  4557 F DEBUG   :     sp   0000007a05afe640  pc   0000007a045a27e4  pstate 0000000040000000
06-26 13:56:23.173  4557  4557 F DEBUG   : 
06-26 13:56:23.173  4557  4557 F DEBUG   : backtrace:
06-26 13:56:23.173  4557  4557 F DEBUG   :     #00 pc 00000000001647e4  /data/app/com.test.app-1/lib/arm64/libjsc.so
06-26 13:56:23.173  4557  4557 F DEBUG   :     #01 pc 000000000016e88c  /data/app/com.test.app-1/lib/arm64/libjsc.so
06-26 13:56:23.173  4557  4557 F DEBUG   :     #02 pc 000000000016ebf0  /data/app/com.test.app-1/lib/arm64/libjsc.so
06-26 13:56:23.173  4557  4557 F DEBUG   :     #03 pc 000000000016ed8c  /data/app/com.test.app-1/lib/arm64/libjsc.so
06-26 13:56:23.173  4557  4557 F DEBUG   :     #04 pc 0000000000005ecc  <anonymous:00000079eb5f9000>

Le retour en arrière ne dit rien de significatif.

Je mentionnerai également que je n'ai pas Android7 officiel sur mon Galaxy S7 car il était impossible de rétrograder à partir d'Android8 (ne pouvait pas produire le problème avec Android8), j'ai donc dû trouver une rom personnalisée qui prendrait en charge Android7.

Je suis en train de tenter de compiler ma propre version de débogage de jsc-android en utilisant votre dernier commit sur jsc-android-buildscripts, mais cela me prendra un certain temps.

Je pense que nous avons le même problème.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.groundspeak.react.adventures <<<

backtrace:
  #00  pc 00000000007e048c  /data/app/com.groundspeak.react.adventures-1/lib/arm64/libjsc.so
  #01  pc 00000000000be650  /data/app/com.groundspeak.react.adventures-1/lib/arm64/libjsc.so
  #02  pc 0000000000489f2c  /data/app/com.groundspeak.react.adventures-1/lib/arm64/libjsc.so
  #03  pc 000000000025fd98  <anonymous>

Par version Android:

Version | Numéro | Pour cent
- | - | -
Android 7.0 | 66 | 100,0%

Par appareil:

Appareil | Numéro | Pour cent
- | - | -
hero2lte | 26 | 39,4%
herolte | 24 | 36,4%
heroltebmc | 16 | 24,2%

J'ai également eu le crash du Galaxy S7 après la mise à jour de RN de 0,58,6 à 0,59,9.

La version npm actuelle de jsc-android fait toujours planter l'application, mais l'utilisation de @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg et de la version JSC 245459.9000.0 corrigé le crash pour moi sur S7.

@ChrisEelmaa Le journal "JavaScriptCore.Version" dans adb logcat est un moyen de confirmer la sélection de la version JSC correcte.
Parce que RN 0.59 a intégré libjsc.so et pickFirst '** / libjsc.so' n'est pas fiable à mon avis.

Une autre façon de confirmer la version JSC serait les étapes suivantes:

1. décompressez /path/to/app.apk
2. chaînes jni / arm64-v8a / libjsc.so | grep -C 1 JavaScriptCore.Version

La sortie devrait être quelque chose comme:

$ strings jni/arm64-v8a/libjsc.so|grep -C 1 JavaScriptCore.Version                                                                                                   
API Wrapper
JavaScriptCore.Version
245459.9000.0

@Kudo merci pour votre correction, cela semble empêcher l'enfer de se produire.

Mes 2 cents là-bas: je n'ai pas jni dossier lib place, alors utilisez cette commande pour vérifier la version après la décompression:

$ strings lib/arm64-v8a/libjsc.so | grep -C 1 JavaScriptCore.Version
API Wrapper
JavaScriptCore.Version
245459.9000.0

Merci @Kudo

J'avais auparavant 0,58.3 natif de réaction, je vois des gens mentionner 0,59 tout le temps, j'ai donc décidé également de mettre à jour. La combinaison d'avoir 0.59.0 et @ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg a semblé faire l'affaire pour moi.

Je ne peux plus produire le crash.

Quelqu'un sait-il si un correctif pour ce problème sera dans la prochaine version RN?

Quelqu'un sait-il si un correctif pour ce problème sera dans la prochaine version RN?

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

@kristerkari
Juste pour confirmer les étapes que vous avez suivies.

Vous avez suivi les instructions ici, https://github.com/react-native-community/jsc-android-buildscripts#for -react-native-version-059

Mais vous avez échangé au lieu d'ajouter "jsc-android": "241213.x.x", , vous avez ajouté @kudo-ci/jsc-android": "^245459.9000.0 à votre package.json? Avez-vous apporté d'autres modifications?

Par exemple, je vois que dans build.grade, vous devriez ajouter implementation "org.webkit:android-jsc:r241213" , cette ligne doit-elle également changer, et si oui, que devrait-elle être?

Je continue à recevoir l'erreur de construction Could not find org.webkit:android-jsc:r241213. ou Could not find org.webkit:android-jsc:r245459.9000.0. Donc je suppose que mon problème utilise la mauvaise référence ici, mais je ne peux pas vraiment dire ce que cela devrait être.

@jacquesdev suivez les étapes de ce guide: https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md

Mes chers,

Juste pour mettre à jour cela avec l' aide de [email protected] ».
J'ai envoyé https://github.com/facebook/react-native/pull/25426 pour avoir le JSC mis à jour dans RN.
Et @kelset l'a également dans RN 0.60 RC.
J'espère que nous pourrons enfin résoudre et clôturer ce problème.
Criez aux gens ici en particulier pour l'aide nécessaire pour vérifier mes versions expérimentées dans les deux sens.
Nous sommes ce qu'on appelle la communauté RN!

Merci @Kudo! Avez-vous une idée si cela a une chance de faire une version 0.59.x, ou est-ce que ce sera probablement juste en 0.60?

Ce serait génial si nous pouvions l 'obtenir en 0.59.x
0.60 a beaucoup de changements de rupture avec AndroidX et les bibliothèques externes.

+1 pour nous, l'introduire dans 0.59.x résoudrait beaucoup de problèmes pour notre
applications.

Vous ne voulez pas vraiment vous diriger vers 0.60 en raison de la prise en charge d'Android X dans
bibliothèques jusqu'à présent.

Le pickFirst pour JSC n'a pas fonctionné pour nous, doit être l'une de nos bibliothèques natives
causant un problème mais il semble toujours choisir la version interne de rn.
(Le projet propre a fonctionné cependant, donc doit être l'un de nos deps à l'origine)

Église

Le sam.29 juin 2019, 19:35 Anurag Dadheech, [email protected]
a écrit:

Ce serait génial si nous pouvions l 'obtenir en 0.59.x
0.60 a beaucoup de changements de rupture avec AndroidX et les bibliothèques externes.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ25TBIFBOI3QWMSPXLP46TN3A5CNFSM4HC77RA2YY3PNVWWK3TUL52ISCI4DFVREXG6300WWWWK3TUL52HS4DFVREXG63TUL52WWWWK3TUL52HS4DFVREX63
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AABPHZ2D5WUEM4S3242ZTYTP46TN3ANCNFSM4HC77RAQ
.

Salut puis-je savoir où ajouter ce "@ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg "?

Salut @Kudo merci pour votre

Dans l'ancien WebKit sans DFG JIT, des plantages se produisent encore, mais le nouveau WebKit 2.24.2 sans DFG JIT semble le résoudre. Je me demande s'il vaut la peine d'essayer ce nouveau WebKit avec DFG JIT activé afin de permettre les performances les plus élevées possible si cela fonctionne.

Je suis d'accord avec certains commentaires avant qu'il serait préférable d'avoir un 0.59.10 avec ce correctif car il sera plus difficile de passer à 0.60 @Kudo @kelset @grabbou @turnrye

J'ai le même problème ici,

Nous ne pouvons pas mettre à niveau vers 0.60 car react-native-maps ne prend pas encore en charge AndroidX, nous ne pouvons pas pousser nos mises à jour vers 0.59.X car S7 & S7 plus plante.

C'est vraiment un problème pour les entreprises qui dépend de react-native

Existe-t-il une solution de contournement pour cela?

Je suis d'accord avec @adnkh , nous ne pouvons pas passer à AndroidX maintenant, mais nous devons résoudre les plantages 0.59.

Vous n'avez pas besoin de passer à la version 0.60 pour utiliser le correctif. Vous devriez pouvoir suivre les instructions sur https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. La version que vous souhaitez installer est 245459.0.0 ou supérieure.

Salut @benoitdion ,

Oui, il est possible de consommer même si ce n'est pas dans la bibliothèque principale, en fait, j'ai suivi ces instructions https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 . et ça a marché

Mais je ne pense pas que ce soit une solution permanente et soignée en raison des nombreuses choses que vous devez ajouter à votre projet Android, je pense qu'un correctif dans RN principal serait plus pratique du point de vue du développeur et résout de nombreux problèmes de plantage sur les applications Android

Vous n'avez pas besoin de passer à la version 0.60 pour utiliser le correctif. Vous devriez pouvoir suivre les instructions sur https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. La version que vous souhaitez installer est 245459.0.0 ou supérieure.

@benoitdion oui, mais c'est une solution de contournement, un correctif officiel publié en tant que 0.59.10 serait mieux.

Merci @Kudo
Utiliser @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg réduit la plupart des plantages
Mais il y a encore quelques plantages dans la production

xiaomi MIX 3 XiaoMi / MIUI Android 9, niveau 28 arm64-v8a

1 #00 pc 00000000000f7748 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const+16) [arm64-v8a]
2 #01 pc 0000000000143fe8 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const+48) [arm64-v8a]
3 #02 pc 000000000012f0a8 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&)+556) [arm64-v8a]
4 #03 pc 0000000000139484 /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 000000000013900c /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)+1044) [arm64-v8a]
6 #05 pc 00000000001fb9c4 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+324) [arm64-v8a]
7 #06 pc 00000000001f8e90 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::SlotVisitor::drain(WTF::MonotonicTime)+132) [arm64-v8a]
8 #07 pc 00000000001f96bc /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)+580) [arm64-v8a]
9 #08 pc 00000000001e41a0 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_17E3runEv+580) [arm64-v8a]
10 #09 pc 00000000006171ec /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 0000000000617950 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::ParallelHelperPool::Thread::work()+16) [arm64-v8a]
12 #11 pc 000000000060de7c /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+376) [arm64-v8a]
13 #12 pc 000000000061b084 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+212) [arm64-v8a]
14 #13 pc 0000000000646dc8 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::wtfThreadEntryPoint(void*)+4) [arm64-v8a]
15 #14 pc 0000000000081dac /system/lib64/libc.so (__pthread_start(void*)+36) [arm64-v8a]
16 #15 pc 0000000000023788 /system/lib64/libc.so (__start_thread+68) [arm64-v8a]

OPPO R9S Oppo / COLOROS Android 6.0.1, niveau 23 arm64-v8a

1 #00 pc 00000000000f7748 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const+16) [arm64-v8a]
2 #01 pc 0000000000143fe8 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const+48) [arm64-v8a]
3 #02 pc 000000000012f0a8 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&)+556) [arm64-v8a]
4 #03 pc 0000000000139484 /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 000000000013900c /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)+1044) [arm64-v8a]
6 #05 pc 00000000001fb9c4 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+324) [arm64-v8a]
7 #06 pc 00000000001f8e90 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::SlotVisitor::drain(WTF::MonotonicTime)+132) [arm64-v8a]
8 #07 pc 00000000001f96bc /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)+580) [arm64-v8a]
9 #08 pc 00000000001e41a0 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_17E3runEv+580) [arm64-v8a]
10 #09 pc 00000000006171ec /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 0000000000617950 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::ParallelHelperPool::Thread::work()+16) [arm64-v8a]
12 #11 pc 000000000060de7c /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+376) [arm64-v8a]
13 #12 pc 000000000061b084 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+212) [arm64-v8a]
14 #13 pc 0000000000646dc8 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::wtfThreadEntryPoint(void*)+4) [arm64-v8a]
15 #14 pc 00000000000664a4 /system/lib64/libc.so (__pthread_start(void*)+52) [arm64-v8a]
16 #15 pc 000000000001ebc4 /system/lib64/libc.so (__start_thread+16) [arm64-v8a]

RMX1901 Oppo / COLOROS Android 9, niveau 28 arm64-v8a

1 #00 pc 0000007772fbb2c0 <unknown>
2 #01 pc 00000000005519bc /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 00000000005722e8 /data/app/com.gezbox.windmessage-vCMpnEKA509f1Di2EyrZ2w==/lib/arm64/libjsc.so (JSC::stringProtoFuncReplaceUsingRegExp(JSC::ExecState*)+3072) [arm64-v8a]
4 #03 pc 0000007772dff1ec <unknown>

👋 tout le monde.

Nous vous entendons tous, et à cause des problèmes que vous rencontrez si nombreux, nous avons réalisé une dernière version du correctif 0.59.10 pour vous fournir la nouvelle version du JSC.

Un grand merci à @Kudo pour son travail de

Nous ne ferons pas d'autres versions 0.59 dans un avenir prévisible, car c'est un travail difficile et encore plus difficile car nous travaillons également sur 0.60 (qui aura aussi le nouveau JSC!).

Je vais fermer cela car le principal problème de base a été résolu, mais je suggérerais d'en ouvrir un nouveau pour les autres plantages que vous pourriez rencontrer après la 0.59.10.

Excellente nouvelle !!

Merci à tous, en particulier @kudo !!

Le mar, 2 juillet 2019, 12:29 Lorenzo Sciandra, [email protected]
a écrit:

👋 tout le monde.

Nous vous entendons tous, et à cause des problèmes que vous rencontrez souvent, nous
a effectué une dernière version du correctif 0.59.10 pour vous fournir la nouvelle version de
le JSC.

Un grand merci à @Kudo https://github.com/Kudo pour son travail sur
en rétrocédant ceci à 0,59.

Nous ne ferons pas de nouvelles versions 0.59, car c'est un travail difficile et même
plus difficile car nous travaillons également sur 0.60 (qui aura le nouveau JSC
aussi!).

Je vais fermer ceci car le principal problème central a été abordé, mais je
suggérer d'en ouvrir un nouveau pour les autres plantages que vous pourriez rencontrer
après 0.59.10.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZZG2Z764HFNPJB7UVTP5M325A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4VMFV76MZWWK3TUL52HS4VFV76MZWWK3TUL52HS4DFV76MZWWK3TUL52HS4DFV76MZWWK3TUL52HS4DFV76MZH0WWWK3TUL52HS4VMX63MZH0WWK3TUL52HS4VLOX63
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AABPHZ5PYT4F7ZZGQXZKKKLP5M325ANCNFSM4HC77RAQ
.

Merci beaucoup pour le correctif! Après la mise à niveau de react-native vers la version 0.59.10 , dois-je encore implémenter les étapes mentionnées ici ?

Kevin,

Après la mise à niveau vers RN 0.59.10, vous n'avez pas besoin de suivre l'essentiel
instructions plus.

K

Le mercredi 3 juillet 2019, 15:42 Kevin Etore, [email protected] a écrit:

Merci beaucoup pour le correctif! Après la mise à niveau de react-native vers la version 0.59.10,
dois-je encore implémenter les étapes mentionnées ici
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 ?

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ6H66HMI6CFMXMR4Y3P5S3DVA5CNFSM4HC77RA2YY3PNVWWWK3TUL52HS4DFVMNVWWWK3TUL52HS4DFVMZ50VWWK3TUL52HS4DFVMZ50VWWWK3TUL52HS4DFVMB
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AABPHZ6UMO5NS4F4OZ7RWPTP5S3DVANCNFSM4HC77RAQ
.

Mon application plante toujours sur Meizu M5s M612H Android OS 6 avec RN-0.59.10. J'ai créé un nouveau problème comme @kelset l'a suggéré.

Crash toujours sur Caterpillar S41 (Android 8.0). Le correctif a résolu le problème sur tous les autres appareils. A également créé un nouveau problème . Dites-moi si ce n'est pas la bonne façon de faire.

salut les gars
Mon application plante également sur certains appareils Android lors de la compilation en 64 bits

Utilisez-vous la version 1.1.0 du package react -native-elements ??
Parce que le composant Header plante mon application et aussi le composant Avatar lorsque je mets l'icône ou le titre de l'accessoire

Quelqu'un d'autre peut-il vérifier si la même chose lui arrive?

tous les propriétaires de s7 ont eu la chance de tester ce problème avec Hermes?

si j'utilise l'application ci-dessous se bloque et acceptée par Google Play Store
ndk {abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"}
si j'utilise l'application ci-dessous fonctionne mais n'est pas acceptée par Google Play
ndk {abiFilters "armeabi-v7a", "x86"}

s'il vous plaît, aidez-moi à résoudre

Se bloque toujours sur Moto G7 et Pixel 2 (tous deux Android 9.0) avec le bras APK 64 bits. Cela fonctionne bien avec l'APK du bras 32 bits.

@ afras21 - c'est parce que le bogue existe dans la version 64 bits, que le Google Play Store rend obligatoire.

@jacquesdev Merci jacq, maintenant ils ont supprimé le obligatoire et maintenant ça marche

@ afras21 vous voulez dire que Google a levé la restriction 64 bits du Playstore?

J'ai le même problème. Si je mets à jour mon projet de 0.59.9 à 0.60.4, devrais-je résoudre le problème?

J'ai le même problème. J'utilise actuellement 0.59.9. Si je passe à la version 0.60.x, le problème sera-t-il résolu?

Veuillez d'abord essayer si 0.59.10 a résolu les problèmes pour vous.
Sinon, cela vaut peut-être la peine de mettre à niveau RN 0.60.4 et d'activer Hermes à la place.

Répéter ce que Kudo a dit, juste plus de contexte et de résumer le contenu précédent de ce numéro (car il est probablement difficile de trier autant de commentaires à ce stade):

Si vous avez 0.59.9 ou moins, il s'agit d'un problème vérifié avec l'ancien JSC. C'est le sujet de centaines de commentaires ci-dessus (et dans d'autres numéros). Le problème n'est pas exclusif au 64 bits, mais se produit le plus souvent avec le 64 bits.

0.60+ a plusieurs changements de rupture, en particulier sur Android.

Si vous ne voulez pas passer par là, essayez 0.59.10 car il a le correctif (comme décrit ci-dessus) intégré directement dans la version / build - et il semble résoudre le problème dans la majorité des cas.

Il y a encore des cas où il y a des problèmes pour certains téléphones (que j'ai également rencontrés), voir # 25494 - si vous avez ceci, je vous suggère de poster vos traces de pile sur ce problème ouvert. Cependant, si vous dites que vous avez 0.59.9, vous pouvez _probablement_ résoudre votre problème en allant à 0.59.10.

@MalcolmScruggs @ntorion @ harryt2
L'avez-vous résolu? Comment résoudre？ Merci

0.59.10 ne l'a pas résolu pour moi. J'essaierai de faire la mise à jour 0.60.x

@MalcolmScruggs @ntorion @ harryt2
L'avez-vous résolu? Comment résoudre？ Merci

0.59.10 ne l'a pas résolu non plus pour moi. Je ne peux pas mettre à niveau vers 0.60.x car certaines de mes dépendances ne fonctionneront pas. Je l'ai compilé sur Hermes, mais j'ai vu un énorme pic dans les ANR (merci à Dieu pour le déploiement par étapes). Toujours assis sur le Play Store avec RN version 0.57.8 mais je ne peux plus mettre à jour mon application à cause de l'exigence de 64 bits. Assez frustré et essayant de décider s'il faut simplement reconstruire l'application entière avec un autre cadre.

@ harryt2 @rogerkerse Merci.
Ma situation est encore pire. La version publiée a des bogues, je dois donc mettre à jour l'application 64. Je ne peux pas résoudre ce problème pour le moment. J'essaye également de flutter, mais pas de remplacement complet si rapide.

En fait, j'ai eu la peine de faire passer React-Native à 0.60.5 et d'activer Hermes + 64 bits (ce qui était pénible, car la mise à niveau de React-Native l'est toujours) et j'ai toujours ces problèmes sur plusieurs téléphones Android (y compris HUAWEI MYA-L41).

J'ai essayé à peu près tout ce que j'ai trouvé dans d'autres threads sans beaucoup de chance, donc je peux vous dire que le fait de cogner réagit-native et que l'utilisation d'Hermes ne résout pas tous ces problèmes.

La mise à jour react-native + Hermes et 64 bits est incroyable sur les autres appareils Android sur lesquels je l'ai exécutée et notre application ne s'est jamais sentie aussi fluide.

Cependant, chaque fois que je teste sur l'appareil spécifique que j'ai mentionné (Huawei), il se bloque instantanément ou après que l'application est ouverte pendant 1 à 2 secondes sans message de panne spécifique, je n'ai pas d'autre appareil que celui-là et un Huawei plus récent ( qui fonctionne parfaitement) donc je ne peux pas vous donner plus d'informations sur les autres téléphones.

Si quelqu'un a fait des progrès avec ce problème ou a des idées pour consigner plus spécifiquement mes problèmes, des conseils sont toujours les bienvenus et je suis prêt à partager toute information concernant ce problème.
Merci aux personnes de ce fil pour avoir proposé des solutions, mais pas de chance pour l'instant. 🙂

@YoranRoels Avez-vous essayé d'exécuter une application propre créée par react-native init? Je me demande si le crash est causé par RN lui-même ou par une bibliothèque ou un code que vous avez écrit.

@armenbadalyan Merci pour la réponse rapide.

Je viens de configurer un nouveau projet et j'ai essayé de l'exécuter sur l'appareil et tout semble bien, donc à la fin, cela semble être quelque chose avec ma configuration. Existe-t-il un moyen efficace de déboguer cela puisque mon logcat ne crache rien d'utile à part com.<our_app_id> a été tué?

React Native 59.10 ne le résout pas non plus pour nous. L'application plante toujours au premier lancement.

@GreanBeetle Voir https://github.com/facebook/react-native/issues/25494. 0.59.10, malheureusement, est connu à ce stade pour ne pas résoudre ce problème dans tous les cas.

Le chemin le plus à jour est d'utiliser (comme dans ce fil), 0.60+ et Hermes.

@YoranRoels Récupère la pierre tombale de l'appareil. Voir: https://github.com/facebook/react-native/issues/24261#issuecomment -490239902

@GreanBeetle Vous pouvez utiliser le moteur V8 sur 0.59.10 pour vous débarrasser de ce problème
https://github.com/Kudo/react-native-v8

Merci @ j-wang. @manuhook va

@GreanBeetle Vous pouvez utiliser le moteur V8 sur 0.59.10 pour vous débarrasser de ce problème
https://github.com/Kudo/react-native-v8

Peut confirmer que cela a résolu le problème pour nous. Les builds 64 bits avec react-native-v8 sur 0.59.10 ne plantent plus et nous pouvons enfin pousser à nouveau les mises à jour sur Google Play. Merci!

J'ai essayé la journalisation tombstone @ j-wang mentionnée mais je ne l'ai jamais vraiment utilisé et c'était un fichier immense qui était difficile à lire, après avoir cherché pendant un moment, je ne semblais pas vraiment trouver une cause racine lisible.

Après avoir suivi les conseils de @armenbadalyan , j'ai commencé à me demander si ce n'était tout simplement pas quelque chose de stupide au début de notre application et bien sûr, lors de la suppression de l'interface utilisateur du premier composant, j'ai remarqué que l'application fonctionnait à nouveau, stable. Donc, après avoir creusé davantage, j'ai remarqué qu'un composant spécifique avait des problèmes où une image était rendue.

Dans ce composant, il y a une chance que nous passions null comme variable source sur un react-native Image . Il m'a fallu un certain temps pour rechercher cela et aucune erreur claire, mais cela a finalement tout résolu pour moi et cela fonctionne sur tous nos appareils de test. Toujours aucune idée de la raison pour laquelle cela n'a pas échoué sur notre autre appareil de test ...

Cela pourrait aider d'autres personnes à simplifier le premier composant de leur application pour s'assurer qu'il ne plante pas sur ce code.

TL; DR : Ceci est probablement complètement hors sujet maintenant, mais à qui cela concerne: N'UTILISEZ PAS null COMME source VARIABLE DE Image , il ne le fait pas ' t fonctionne sur tous les appareils. 😅

@ harryt2 oui, moi aussi. J'ai eu un énorme pic d'ANR après ma mise à niveau vers RN 0.60. +

Un peu d'aide à ceux qui essaient encore de résoudre le crash de démarrage:

1. exécuter adb logcat dans une console
2. attendre l'arrêt du spam de la console
3. ouvrez l'application qui plante sur votre appareil
4. arrêtez le logcat adb avec un Ctrl + c
5. faites défiler vers le haut et trouvez le crash

Cela ne résout pas le problème mais vous permet d'en savoir plus. J'ai 2 applications, l'une fonctionne bien avec le 64 bits, toujours en difficulté sur l'autre même si elles ont la même configuration. Mon appareil qui plante est un One Plus 5t (64 bits)

Je viens de le voir sur une nouvelle version de notre application, construite avec RN 59.10, en particulier sur un Samsung Galaxy Note9 sur Android 9. Quelqu'un d'autre voit-il un problème similaire?

@msspshaw Comme mentionné ci-dessus et dans l'autre numéro, oui. Le nouveau JSC se fige / se bloque de manière aléatoire sur certains appareils Android car il est collecté de manière non déterministe, puis l'application entière se bloque.

La solution consiste à passer à la version 0.60+ et à utiliser Hermes, ou à changer JSC pour la v8.

J'ai essayé la journalisation tombstone @ j-wang mentionnée mais je ne l'ai jamais vraiment utilisé et c'était un fichier immense qui était difficile à lire, après avoir cherché pendant un moment, je ne semblais pas vraiment trouver une cause racine lisible.

Après avoir suivi les conseils de @armenbadalyan , j'ai commencé à me demander si ce n'était tout simplement pas quelque chose de stupide au début de notre application et bien sûr, lors de la suppression de l'interface utilisateur du premier composant, j'ai remarqué que l'application fonctionnait à nouveau, stable. Donc, après avoir creusé davantage, j'ai remarqué qu'un composant spécifique avait des problèmes où une image était rendue.

Dans ce composant, il y a une chance que nous passions null comme variable source sur un react-native Image . Il m'a fallu un certain temps pour rechercher cela et aucune erreur claire, mais cela a finalement tout résolu pour moi et cela fonctionne sur tous nos appareils de test. Toujours aucune idée de la raison pour laquelle cela n'a pas échoué sur notre autre appareil de test ...

Cela pourrait aider d'autres personnes à simplifier le premier composant de leur application pour s'assurer qu'il ne plante pas sur ce code.

TL; DR : Ceci est probablement complètement hors sujet maintenant, mais à qui cela concerne: N'UTILISEZ PAS null COMME source VARIABLE DE Image , il ne le fait pas ' t fonctionne sur tous les appareils. 😅

+1 Fonctionne pour moi. J'ai eu les mêmes problèmes. Merci!

Voyez également cela se produire sur un Samsung Galaxy S7 IO-IL 086 sur Android 7.0 RN 0.59.10

@BracketMan Utilisez -vous V8 au lieu de JSC?

@EmilScherdin ahhh non, je ne le suis pas. Je vais essayer et rendre compte des remerciements.

@EmilScherdin Je peux confirmer que courir sur V8 sur RN 0.59.10 fonctionne pour moi, plus de plantages.

Merci!

Nous rencontrons le même problème sur RN 0.59.10 avec la v8. Je vois que JIT n'est pas désactivé pour arm64-v8a et sur les appareils avec cette architecture, nous avons des plantages.

@mmamoyco Avez-vous le stacktrace du crash du V8?

@Kudo Ouais, j'ai le journal des plantages. Nous sommes passés à la v8 de jsc car nous subissions de nombreux plantages. Mais la même chose se produit avec la v8. ci-dessous est le journal

00 pc 0000000000c31dd8 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so

# 01 pc 0000000000c3437c /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 02 pc 0000000000c30554 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 03 pc 0000000000c33070 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 04 pc 0000000000bf2e94 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so (v8 :: internal :: ItemParallelJob :: Task :: RunInternal () + 24)
# 05 pc 0000000000a4d660 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so (v8 :: platform :: DefaultWorkerThreadsTaskRunner :: WorkerThread :: Run () + 56)
# 06 pc 0000000000a4a074 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 07 pc 0000000000067ec4 /system/lib64/libc.so (__pthread_start (void *) + 36)
# 08 pièce 000000000001f2f4 /system/lib64/libc.so (__start_thread + 68)

Nous avons eu ce problème exact sur 0.59.1 et avons pu le résoudre en procédant comme suit:

⛄️ Ces instructions ne sont fichier README jsc-android . Nous avons modifié les numéros de version et certains signifiants. La version canary de jsc ne résout pas le problème. C'est la version après jsc-android @ canary qui est nécessaire, voir: Ce correctif pour le correctif original qui a été fusionné dans le repo react-native. Merci à @ ravali121 pour avoir aidé à résoudre ce problème.

1. Ajoutez jsc-android à la section "dépendances" de votre package.json :

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

puis exécutez npm install ou yarn (selon le client npm que vous utilisez) pour que la nouvelle dépendance soit installée dans node_modules

1. Modifiez le fichier android/build.gradle pour ajouter le nouveau référentiel maven local emballé dans le package jsc-android au chemin de recherche:

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

1. Mettez à jour le fichier build.gradle votre application situé dans android/app/build.gradle pour ajouter la dépendance JSC. Veuillez vous assurer que la dépendance est antérieure à la dépendance React Native.

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
}

1. Mettez à jour le fichier build.gradle votre application situé dans android/app/build.gradle pour utiliser la première bibliothèque JSC correspondante.

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'
+    }
}

quelqu'un pourrait-il aider à répondre à cette question?
https://github.com/react-native-community/jsc-android-buildscripts/issues/127

N'UTILISEZ PAS null COMME source VARIABLE DE Image , cela ne fonctionne pas sur tous les appareils. 😅

Je déteste juste vous citer mais j'ai failli manquer votre solution dans le bruit de ce fil. Merci beaucoup @YoranRoels !! Cela a sauvé la journée!

Je trouve un test de la source Image machine réelle en de @YoranRoels définie source variable Image à {null} et {{ uri: null }} mais ça ne plante toujours pas, Horrible je ne sais même pas comment c'est arrivé, quelqu'un peut-il m'aider.

Nous avons eu ce problème exact sur 0.59.1 et avons pu le résoudre en procédant comme suit:

⛄️ Ces instructions ne sont fichier README jsc-android . Nous avons modifié les numéros de version et certains signifiants. La version canary de jsc ne résout pas le problème. C'est la version après jsc-android @ canary qui est nécessaire, voir: Ce correctif pour le correctif original qui a été fusionné dans le repo react-native. Merci à @ ravali121 pour avoir aidé à résoudre ce problème.

1. Ajoutez jsc-android à la section "dépendances" de votre package.json :

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

puis exécutez npm install ou yarn (selon le client npm que vous utilisez) pour que la nouvelle dépendance soit installée dans node_modules

1. Modifiez le fichier android/build.gradle pour ajouter le nouveau référentiel maven local emballé dans le package jsc-android au chemin de recherche:

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

1. Mettez à jour le fichier build.gradle votre application situé dans android/app/build.gradle pour ajouter la dépendance JSC. Veuillez vous assurer que la dépendance est antérieure à la dépendance React Native.

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
}

1. Mettez à jour le fichier build.gradle votre application situé dans android/app/build.gradle pour utiliser la première bibliothèque JSC correspondante.

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'
+    }
}

Tu es un sauveur! ❤️ Cela fait trois jours que je cherche votre réponse pour coller ce code et changer la version de jsc-android exactement à celle que vous avez mentionnée. Et ça marche maintenant! Une erreur s'est produite lorsque j'ai mis à niveau la version RN de 0,59 à 0,60. L'application était cassée pour seulement l'androïde, iOS était bien. Le plus étrange, c'est que l'application a été compilée avec succès, donc tout avait l'air bien, mais quand elle a été lancée, elle s'est immédiatement plantée.