Gracias por enviar tu problema. ¿Puedes echar otro vistazo a tu descripción y asegurarte de que la plantilla del problema se haya completado en su totalidad?

👉 Haga clic aquí si desea volver a ver la plantilla de problemas del informe de errores.

Gracias por enviar tu problema. ¿Puedes echar otro vistazo a tu descripción y asegurarte de que la plantilla del problema se haya completado en su totalidad?

👉 Haga clic aquí si desea volver a ver la plantilla de problemas del informe de errores.

Actualizado

Captura de pantalla de error de Logcat para referencia

publicando compilación dividida de 64 bits también recibo este bloqueo en el lanzamiento en Galaxy S7 y Galaxy S7 Edge con Android 7.0
Android vitals mostrando:
señal 11 (SIGSEGV), código 1 (SEGV_MAPERR) WTFCrash
retroceso:
# 00 pc 00000000007e048c /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (WTFCrash + 16)
# 01 pc 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 pieza 000000000019e27c

en Crashlytics para los dispositivos que obtengo:
Excepción fatal: com.facebook.react.common.c
Violación invariante: la reanudación del trabajo aún no se ha implementado.

la solución alternativa de solo proporcionar una compilación de 32 bits está resolviendo esto por ahora

Veo exactamente los mismos errores que @nadavmos en Galaxy S7 con Android 7.0. La aplicación falla al iniciarse

Veo exactamente los mismos errores que @nadavmos en Galaxy S7 con Android 7.0. La aplicación falla al iniciarse

@nsantacruz , ¿también estás usando react-navigation? parece común a todos los demás reporteros

@nadavmos , no estoy usando react-navigation . Muy bien, tal vez sea el mismo problema que # 24260, ya que ese problema también afecta a 0.59 con Samsung S7 en Android 7.0

@nadavmos El bloqueo no está relacionado con react-navigation , de hecho, la aplicación se bloquea en un nuevo proyecto RN creado a través de react-native init.

@hramos @mkonicek A partir de ahora podemos concluir que esto parece ser un problema con la última versión de RN 0.59, que afecta a las compilaciones de Android que se ejecutan en Samsung S7 , S7 Edge después de que proporcionamos soporte para arm64-v8a , x86_64 , eliminarlos de build.gradle no bloquea la aplicación, lo que podría afectar a las aplicaciones que se activan después de 1 August 2019 según la política de soporte de Google Play de 64 bits. Nos gustaría que llamaran la atención, por favor.

También sucede en 0.58.5. Galaxy S7. Android 6.0. Configurarlo en 32 bits tampoco funciona.

Estamos observando los mismos bloqueos en compilaciones de 64 bits de RN 0.59.4 en un Galaxy S7 con Android 7.0. Lamentablemente, no tenemos acceso a ese modelo de dispositivo. Funciona bien en todos los nuestros.

Tener el mismo problema con el dispositivo Huawai P9 en el siguiente entorno:

  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

Este es el seguimiento de la pila de Crashlytics que obtenemos:

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

Tener el mismo problema con Samsung Galaxy S7, en 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)

~ Agregar esto a su android/app/build.gradle ~ puede solucionarlo ~ (no lo hizo): ~

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

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

Gracias por intentar ayudar, pero la solución no nos ha ayudado.

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

Agregar esto a su android / app / build.gradle puede solucionarlo:

packagingOptions {
pickFirst ' /libjsc.so'pickFirst ' /libc++_shared.so'
}
Consulte react-native-community / jsc-android-buildscripts # 95 https://github.com/react-native-community/jsc-android-buildscripts/pull/95
Probando esto ahora.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/facebook/react-native/issues/24261#issuecomment-483728028 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/ AEO_1BMzddSncn2DtQeDcx_y1KIz0ZSGks5vhfaJgaJpZM4cX_xB .

Agregar esto a su android/app/build.gradle puede solucionarlo:

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

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

Estoy probando esto ahora.

@AndrewJack , ¿te

Agregar esto a su android/app/build.gradle puede solucionarlo:

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

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

Estoy probando esto ahora.

Lamentablemente, ya los teníamos allí.

Hemos extraído nuestras compilaciones de 64 bits de Play Store. Es posible que esto no esté relacionado en absoluto con el bloqueo en la compilación de 64 bits, pero los dispositivos Galaxy S7 que ejecutan la compilación armeabi-v7a ahora se bloquean mucho como se indica a continuación. Inmediatamente después del inicio.

Realmente me pregunto qué tiene de diferente el S7 en comparación con otros dispositivos.

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 No funcionó, pensé que corregir la configuración jsc-android-buildscripts podría funcionar.

Recibo la misma excepción y no puede ser detectada por un controlador de excepciones no detectado. En mi aplicación de Android probé este código:

Thread.setDefaultUncaughtExceptionHandler(...);

con el controlador, que solo escribe el nombre de la excepción en la consola y luego devuelve el control al controlador predeterminado, pero ese código no se había ejecutado antes de la falla de la aplicación.

Estaba tratando de investigar por qué Crashlytics no registra estas excepciones. Tal vez esa sea la razón ... Recuerdo que una o dos veces he visto bloqueos nativos en mi consola de estructura, por lo que crashlytics puede registrar bloqueos nativos, pero de alguna manera no en este caso.

@SpertsyanKM El bloqueo se produce en el nivel ndk. No verá el bloqueo en la consola de base de fuego, a menos que agregue la biblioteca Crashlytics NDK. https://docs.fabric.io/android/crashlytics/ndk.html

Como ha encontrado, Thread.setDefaultUncaughtExceptionHandler solo detectará excepciones de Java.

Actualicé a RN 0.59.5 hoy y el bloqueo aún ocurre. Este problema aún no se ha solucionado.

Hola a todos, tengo el mismo problema en 0.59.5, elimine android: screenOrientation = "portrait" en AndroidManifest.xml. Esto funciona para mi.

@Jeijie Ya no tenía eso allí, pero se estrelló de todos modos.

mismo problema en REDMI NOTE 4X Android 7.0 y 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]

El mismo problema en Galaxy S7 Edge / Android 7.0 y con tres versiones diferentes de React-Native: 0.58.4, 0.58.5 y 0.59.5.
El bloqueo no se ha detectado en otros dispositivos Android.

Actualmente, la única solución para evitar este problema es compilar la aplicación solo en 32 bits. Pero el problema debe solucionarse para el primer mes de agosto porque Play Store ya no aceptará aplicaciones de solo 32 bits.

Experimentando lo mismo, limitado a Galaxy S7 con Android <= 7.0 (no 8.0). Sucede desde que habilitamos el soporte de 64 bits.

A partir de nuestra configuración predeterminada de gradle, ni siquiera admitimos 64 bits y, sin embargo, los bloqueos ocurren.
''
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 
}```

Uno más aquí, he notado que el problema también ocurre con algunos dispositivos Mediatek
Alcatel A5 (ELSA6)
Alcatel 1x / TCL L9 (U5A_PLUS_4G)
Algunos otros dispositivos con SoC de MediaTek con soporte x64

Hola. Hemos encontrado que:

1. ~ La solución para eliminar el soporte de 64 bits funciona ~ Esto solo solucionó el problema para algunos de nuestros usuarios
2. ~ Hemos tenido usuarios que solucionan este problema ellos mismos _ reiniciando su teléfono_ (no es necesario cambiar a la aplicación de 32 bits) ~ No tenían el mismo problema.

Puedo confirmar que eliminar el soporte de 64 bits redujo los informes de fallas en ~ 90%
Todavía está sucediendo con algunos dispositivos. Pero la "solución" actual es lo mejor que puedo hacer ahora

También tengo fallos en OnePlus 3, pero eliminar el soporte de 64 bits no ayuda. Recibo fallas con un proyecto de inicialización nativo de reacción limpio (también en emuladores al abrir el APK de la aplicación).

El mismo problema s7 edge android 7.0 se bloquea en producción con división de paquete, otros parecen estar bien
señal 11 (SIGSEGV), código 1 (SEGV_MAPERR)
retroceso:
# 00 pieza 000000000009e144
# 01 pieza 00000000000a4a70

Este problema ya está identificado en el repositorio de webkit. He comentado allí cuando descubrí este problema hace meses: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/327#issuecomment -436781890

Sería genial coordinar los esfuerzos.

Nota: en Youi utilizamos RN de forma no estándar. Creamos nuestro propio JSC de 64 bits, por lo que resolvimos este problema mucho antes, antes de la versión 0.58.

Los factores comunes parecen ser los dispositivos Android 6.0 o 7.0 (nivel 23 y 24) y ARM 64.
El dispositivo más común con esta combinación es el S7. Actualizar un S7 a Android 8 soluciona el problema.

He reproducido el bloqueo en un emulador de Android ARM de 64 bits, pero las imágenes del emulador de Android ARM son demasiado inestables y con errores para trabajar. También tengo un S7 para depurar, que estoy intentando degradar a Android 7, aunque Samsung no lo ha hecho fácil.

@kmagiera & @kudo , recientemente lanzó una nueva versión de JSC. ¿Espera que esta versión solucione este problema? ¿Sería útil alinear las versiones del NDK? https://github.com/react-native-community/jsc-android-buildscripts/pull/95

@AndrewJack La nueva versión solo para parches de seguridad de WebKit y eliminación de libc ++ _ shared.so para https://github.com/facebook/react-native/pull/24672. No creo que esto solucione los problemas de bloqueo.

AFAIK, hay varios tipos de fallas JSC.
Algunos son de operationLinkDirectCall como se informó este problema y algunos son NPE como https://github.com/react-native-community/jsc-android-buildscripts/issues/84.
La mayoría de ellos están relacionados con JIT.
La ruta de bloqueo de JIT es difícil de reproducir internamente y también es difícil de solucionar.
Tengo algunas posibles soluciones, pero no estoy seguro de si realmente resolverán el problema del bloqueo.

• Una de las soluciones es desactivar DFG_JIT .

• También hay una solución de la operación relacionada con el flujo ascendenteLinkDirectCall

• El JSC más nuevo (WebKitGTK 2.24) incluye muchos cambios JIT. Vale la pena intentarlo si la actualización ayuda.

En mi opinión, si la reproducción interna no es posible, una alternativa es ofrecer una construcción experimentada.

Mi plan es facilitar la actualización de JSC, simplemente yarn add jsc-android@experiment . Esto debería suceder en la RN 0,60.
Con este mecanismo, al menos podríamos estar un paso adelante para solucionar los problemas de bloqueo.

Por otro lado, ayudaría si hay un código y un entorno de reproducción fiables.
Por ejemplo, hay un repositorio de react-native-navigation. Ayuda mucho.
https://github.com/react-native-community/jsc-android-buildscripts/issues/84#issue -407898908

El bloqueo también ocurre en Pixel 2 con Android 9, si eso ayuda.
¿Hay alguna forma de obtener registros de fallos al ejecutar APK? Estaré encantado de ayudar a obtener más información sobre estos fallos, pero no sé mucho sobre el desarrollo de Android.

@quietbits , la mayoría de los registros relacionados con estos problemas no son muy útiles, pero para sacarlos:

Busque cuándo ocurre el bloqueo usando adb logcat ; se verá así (no exactamente, ya que acabo de extraer esto de la parte superior del registro, pero muestra un extracto, por lo que lo estoy señalando fuera):

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

También suele decir que el registro está escrito en una "lápida".

Para quitar la lápida, use adb bugreport ./MySuperSpecialBugReport y la última parte obviamente es la ruta en la que lo desea.

Lo sacará como un zip, y puede descomprimirlo, navegar (en la mayoría de los dispositivos) a: ./MySuperSpecialBugReport/FS/data/tombstones y luego puede abrir la lápida con su editor de texto.

Una vez más, dada la naturaleza de estos accidentes, no son muy informativos. Al menos con los nuestros, suelen estar con mqt_js y en una dirección de puntero bajo. También todavía ocurren (aunque cada vez menos extraño / impredecible) con apks de 32 bits solamente.

===

@ Kudo: definitivamente estoy deseando poder probar diferentes JSC con mayor facilidad y ver qué hace. Este ha sido un verdadero problema hasta ahora en la actualización a 0.59 con bloqueos súper no deterministas e impredecibles (que también solo ocurren en ciertos dispositivos ... a veces).

Para obtener el backtrace simbolizado, solía combinar adb logcat y ndk-stack
Por ejemplo, apuntando a RN 059 stock JSC (que es [email protected]) y 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

¿Alguna actualización sobre este tema?

Eliminar 64 bits no es una solución según Google Play 64 bit support policy. Podría afectar potencialmente a las aplicaciones que se activan después de 1 August 2019 . Nos gustaría tener una solución adecuada para este problema. @hramos alguna actualización sobre esto? Por favor llame la atención.

Hola a todos, tengo el mismo problema en 0.59.8,
Nos gustaría tener una solución adecuada para este problema.

Hola,
Estoy ayudando con el problema del bloqueo de JSC y también soy colaborador de jsc-android-buildscripts.
RN 0.59 JSC es de hecho de jsc-android-buildscripts .

Para solucionar el problema del bloqueo, necesitamos el seguimiento del bloqueo.
Con suerte, siga los pasos a continuación para obtener un seguimiento y publicar aquí.
Luego podría hacer un seguimiento para encontrar posibles soluciones.

Instale ndk-build y ejecute comandos:

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

Parece que muchos fallos provienen de Samsung S7. Desafortunadamente, no tengo S7 a mano.
Con suerte, obtener información útil para continuar con la solución de problemas.

@marlonchalegre

@Kudo Este es el registro que obtuve ejecutando esos comandos en un proyecto nuevo en RN 0.59.8
Intenté crear compilaciones de depuración y liberación y compilar el jsc yo mismo con los registros parecía igual en cada caso.

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

Tengo un S7 a mano y estaría feliz de intentar ejecutar cualquier otra cosa para intentar resolver esto.

Mi sugerencia es volver a compilar el JSC con JIT deshabilitado . Es posible que los mecanismos de seguridad en el sistema operativo interfieran con los JIT
operaciones de alguna manera impredecible.

He reproducido los mismos registros de fallos que @MalcolmScruggs. En un S7 - Android 7.1.2 - LineageOS 14.1.

En RN 0.59.8 y la última versión de la rama maestra .

No se requieren cambios para reproducir el bloqueo. La plantilla RN predeterminada provoca un bloqueo después de tocar un poco la pantalla.

Repositorio aquí: https://github.com/AndrewJack/jsc_crash/tree/rn_master_branch
Los registros de fallos están en el

Próximos pasos: cree su propia versión de JSC con JIT deshabilitado

Si alguien tiene un S7 en una versión más reciente de Android y quiere degradarlo. Esto es lo que hice:

Descarga este software:

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

1. Instale la recuperación TWRP (usando odin [requiere Windows] u otro método)
2. Arrancar en recuperación
3. montaje de almacenamiento
4. copiar el paquete rom & gapps de LineageOS
5. instalar imágenes flash de LineageOS y gapps
6. reiniciar.

Con el último maestro nativo de reacción y usando no_dfg_jit o no- jit de la bifurcación de

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

@AndrewJack Increíble, encontraste mis construcciones experimentadas tan rápido.
Gracias por sus comentarios y es bueno saber que estas versiones solucionaron el bloqueo por usted.

Queridos,

Tenía dos versiones de JSC experimentadas, por favor intente si estas pueden solucionar los bloqueos por usted.
Unos breves pasos aquí:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Una versión experimentada consiste en desactivar un tipo de JIT.
Y el otro deshabilita JIT totalmente de @matthargett recomendado.
Si las dos versiones solucionarán el bloqueo por usted, también envíenos sus comentarios sobre el rendimiento general y el TTI como se menciona en mi esencia.

@Kudo ¡ Gracias por eso! ¿Qué sabe sobre GC concurrente en esas compilaciones? Vi que se mencionó en alguna parte que era otra diferencia en comparación con la versión de 32 bits, pero, por supuesto, ya no puedo encontrar ese comentario. Puede ser otra cosa con la que valga la pena jugar en caso de que persistan los bloqueos.

@wbercx ¿Te refieres a GC concurrente o JS concurrente (JIT concurrente)?
De forma predeterminada, la GC concurrente solo está habilitada para arm64 y x64.
Es posible que el GC concurrente no se relacione con el problema del bloqueo. Es probable que se trate de gestión de montones y no de JIT.

JS concurrente está deshabilitado para mis dos compilaciones.
(De forma predeterminada, solo estará habilitado para ENABLE(DFG_JIT) && USE(JSVALUE64) )

Por cierto, JIT en JavaScriptCore es complicado y no soy un experto en esto.
Siéntase libre de señalar si me equivoqué.

@Kudo Probé tus versiones JSC experimentales no-jit y no-dfg-jit y no pude reproducir el bloqueo. Esto parece estar en línea con lo que informó @AndrewJack .

Estaba probando esto en un proyecto básico, así que no puedo comentar sobre ningún impacto en el rendimiento.

Tengo más información, también veo este bloqueo en:
Samsung Galaxy S7 (herolte), Android 7.0
Oppo F7 (CPH1819), Android 8.1

También sucede en 0.58.5. Galaxy S7. Android 6.0. Configurarlo en 32 bits tampoco funciona.

El bloqueo sigue ocurriendo aquí también después de volver a 32 bits

@MalcolmScruggs Es un placer escuchar que las dos versiones experimentadas solucionan el bloqueo por usted.
Estoy pensando en deshabilitar DFG_JIT, al menos la opción JIT está alineada con el JSC antiguo.

@Kudo ¿Está planeando DFG_JIT solo en los dispositivos / CPU afectados?

¿Alguien intentó con la última versión de React Native (0.59.8) que está solucionando algunos fallos (mencionados en la nota de la versión)?
https://github.com/facebook/react-native/releases

¿Alguien intentó con la última versión de React Native (0.59.8) que está solucionando algunos fallos (mencionados en la nota de la versión)?
https://github.com/facebook/react-native/releases

En mi caso, estaba usando 0.59.8, desde entonces volví a 0.57.8 ya que nada más parecía funcionar. Este error es particularmente grave porque hace que la aplicación se bloquee inmediatamente al abrirse. Mi aplicación se cortó bastante en las reseñas.

Estos dispositivos tienen una señal de bloqueo, pero solo muestra una ubicación de memoria.

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

Estos dispositivos parecen aparecer con un error similar a == / lib / arm64 / libjsc.so . No sé lo suficiente sobre el funcionamiento interno para saber qué significa eso, pero espero que ayude.

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

Puedo agregar algunos dispositivos a la lista de @ harryt2.

Señal 11 falla con solo una ubicación de memoria:

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 lista continúa con ~ 65 dispositivos diferentes y la versión de Android entre 7.0 y 9.0.

El error no siempre ocurre en estos dispositivos. Pero es una preocupación real, ya que la tasa de fallas de mi aplicación reportada en Google Play cambió de 0.16% a 1.02% después de la actualización de 0.57.8 a 0.59.5.

0.57.8:

0.59.5:

No soy un experto en el desarrollo de Android, ni entiendo de dónde viene este bloqueo. Puedo proporcionar más datos si ayuda.

@ntorion en nuestro proyecto, todavía vemos estos bloqueos en Samsung s7 con react-native 0.59.8, me temo.

¿Alguna solución para esto en este momento?
Probé en dos Galaxy Note 9 diferentes, todos los teléfonos se bloquean inmediatamente

{"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 usa la instrucción @Kudo https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

@matpaul @Kudo Puedo confirmar que esta compilación experimental de js core parece solucionar el problema para nosotros también (probado en Samsung s7).

Mis fallas relacionadas con este rastro desaparecieron en Android cuando bajé la calificación a 0.58.6 . Estaba planeando tener que degradar a 57.6 , pero 58.6 parece haber solucionado esto por mí (aunque hay algunos otros problemas de Android que tuve que mitigar, donde tengo que compilar manualmente para su lanzamiento)

@Kudo

Queridos,

Tenía dos versiones de JSC experimentadas, por favor intente si estas pueden solucionar los bloqueos por usted.
Unos breves pasos aquí:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Una versión experimentada consiste en desactivar un tipo de JIT.
Y el otro deshabilita JIT totalmente de @matthargett recomendado.
Si las dos versiones solucionarán el bloqueo por usted, también envíenos sus comentarios sobre el rendimiento general y el TTI como se menciona en mi esencia.

@Kudo tuve dos observaciones aquí, como también se menciona en su esencia

• La aplicación se bloquea con la dependencia @kudo-ci/jsc-android@241213-no-dfg-jit , cuando se usa una de nuestras aplicaciones de producción durante unos minutos.
• La aplicación está funcionando bien con @kudo-ci/jsc-android@241213-no-jit dependencia as of now y TTI sigue siendo el mismo / imperceptible con respecto a las compilaciones anteriores.

Kudo, ¿su solicitud de extracción será suficiente para solucionar esto, ya que noté que la aplicación se cuelga cuando la probé con no_dfg_jit

Algunas actualizaciones más aquí:
Realmente dudo que el bloqueo nativo ocurra fácilmente en S7 edge, debería haber otras aplicaciones que enfrenten tales problemas.
¡Te tengo!
El servicio Google Play con API de texto tuvo estos problemas, pero no se corrigió el OSS
Mono encontró un problema de bloqueo en S7 Exynos bit.LITTLE arch y aquí está la solución .

JavaScriptCore usó __clear_cache en ARM64Assembler.
Tendré otra compilación experimentada para parchear __clear_cache más adelante esta semana.

Las compilaciones experimentadas que __clear_cache tienen listas.

Los pasos son los mismos que antes, pero solo para usar una dependencia de npm diferente.

1. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-dfg' y adb logcat confirmado con la versión 241213.8000.0 ( ref código fuente aquí )
2. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg' y adb logcat confirmado con la versión 241213.9000.1 ( ref código fuente aquí )

Lo siento, no puedo volver a verificar el problema del bloqueo, pero solo para verificar las funciones básicas.
Si es posible, ayude a probar los dos JSC experimentales.
Muchas gracias a todos y deséenos buena suerte esta vez.

cc @AndrewJack @MalcolmScruggs @tijs @ishantsagar @timhatch

@Kudo Ahora he recibido comentarios sobre las compilaciones de prueba usando @kudo-ci/jsc-android@241213-fix-clear-cache-dfg y @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg .
Ambas versiones de prueba parecen estar libres de fallas hasta ahora en el Samsung Galaxy S7 Edge / Android 7.0 (hasta ahora la combinación problemática)

@Kudo Probé tanto @kudo-ci/jsc-android@241213-fix-clear-cache-dfg como @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg en un proyecto básico que ejecuta React-Native 0.59.8 y en ambas versiones el bloqueo no ocurre. Probé en un Samsung Galaxy S7 en 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 Probé el último @kudo-ci/jsc-android@241213-fix-clear-cache-dfg pero encontré un bloqueo en un Samsung Galaxy S5 (SM-G900F), similar al que tuvimos con JSC en React Native 0.59.8

La versión sin JIT funcionaba perfectamente ( @kudo-ci/jsc-android@241213-no-jit ) y no he encontrado ningún bloqueo en esa, independientemente de cuánto haya llevado la aplicación al límite. Así que creo que nos quedaremos con ese por ahora.

Estamos usando ReactRootViews en un visor, por lo que creamos y destruimos instancias nativas de reacción con bastante frecuencia, y eso parece desencadenar este bloqueo. Probablemente por eso nos encontramos con este problema con más frecuencia que la mayoría. Estamos volviendo a visitar el enfoque de visor en este momento, pero mientras tanto, espero que este registro de fallos pueda ser útil. (es para la versión 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>

Lamentablemente, ya los teníamos allí.

Hemos extraído nuestras compilaciones de 64 bits de Play Store. Es posible que esto no esté relacionado en absoluto con el bloqueo en la compilación de 64 bits, pero los dispositivos Galaxy S7 que ejecutan la compilación armeabi-v7a ahora se bloquean mucho como se indica a continuación. Inmediatamente después del inicio.

Realmente me pregunto qué tiene de diferente el S7 en comparación con otros dispositivos.

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)

Hemos visto esto internamente y notamos que algunas de nuestras propiedades de estilo devolvían nulo condicionalmente. Eliminar eso y agregar solo condicionalmente la propiedad de estilo solucionó una excepción similar: ¿podría estar sucediendo algo con un tipo de módulo nativo para el suyo?

@tuncaulubilge Gracias por la información.
Solo para confirmar que Samsung S5 (SM-G900F) es de arquitectura arm (no arm64), ¿verdad?
Puede verificar antes de adb shell getprop ro.product.cpu.abi
Según su registro de fallos, parece estar armado.

Si es así, supongo que la causa raíz debería ser otra historia más que aquí.
¿Has probado alguna vez la versión no-dfg-jit, es decir, @kudo-ci/jsc-android@241213-no-dfg-jit o @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg ?
Estas dos versiones deberían ser iguales en arm32, puede probar cualquiera de ellas.

@Kudo ACTUALIZAR

El backtrace informado a través de la consola del desarrollador para el problema original (fallas repetibles al iniciar la aplicación en [exclusivamente] Samsung S7 Edge + Android 7.0) se ve así:

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

El problema original parece solucionarse con cada una de las siguientes compilaciones:
@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

Sin embargo, he logrado estimular otro bloqueo en dos ocasiones para el último de estos ( @kudo-ci/jsc-android@241213-fix-clear-cache-dfg ) en un dispositivo diferente y con un retroceso diferente:

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

Aunque logré bloquear la aplicación de prueba dos veces, cada vez con la misma firma, el bloqueo no se puede repetir sistemáticamente y ocurre durante la navegación entre diferentes pantallas en la aplicación de prueba y no durante el inicio. Como el dispositivo relevante está a mano, he podido extraer un rastro más completo del dispositivo que dice lo siguiente:

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>

y

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

No tengo idea de si esto ayuda, la depuración e interpretación de fallas en Android no es algo que haya hecho antes

@Kudo Aquí están mis hallazgos:

El Samsung S5 cuesta armeabi-v7a . He probado las 4 alternativas que me ha proporcionado, y la que no tiene jit parece ser la única que no tiene problemas. Desactivar dfg reduce bastante la tasa de fallas, pero aún podría fallar.

También estoy probando en un Pixel XL ( arm64-v8a ) y aún no he encontrado fallas en kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg pero la falla es difícil de reproducir en dispositivos de gama alta, ya que la causa principal parece ser ser presión de memoria baja.

Para resumir:
@kudo-ci/jsc-android@241213-no-jit : esto no tiene problemas en ambos dispositivos
@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg : esto falla en los dispositivos de gama baja, no se puede reproducir en los de gama alta
@kudo-ci/jsc-android@241213-fix-clear-cache-dfg : esto se bloquea con más frecuencia que la otra compilación en un dispositivo de gama baja. (aún mejor que el stock RN 59 jsc)
@kudo-ci/jsc-android@241213-no-dfg-jit : Esto también se bloqueó en dispositivos de gama baja, no lo he probado en una gama alta.

Incluso la compilación sin jit es considerablemente más rápida que los JSC estándar, por lo que planeamos usar @kudo-ci/jsc-android@241213-no-jit y lo probaremos más para asegurarnos de que esté listo para producción.

Muchas gracias por toda la ayuda por cierto. Avísame si puedo ser de ayuda

@timhatch @tuncaulubilge Gracias por sus impresionantes pruebas y comentarios sistemáticos.
En este momento, realmente no tengo idea de cómo solucionar el problema.
Ni deshabilitar DFG ni arreglar __clear_cache ayuda con eso.
Además, el bloqueo también ocurre en arm32 (y la causa raíz puede ser diferente a arm64)

En mi opinión personal, me gustaría deshabilitar JIT de forma predeterminada, al menos para asegurarnos de que primero tengamos un JSC sin fallas.
Por cierto, @tuncaulubilge, ¿cómo midió que @kudo-ci/jsc-android@241213-no-jit sea ​​más rápido que el JSC estándar?
Solo por curiosidad, ya que del resultado de la prueba de rendimiento, la versión no-jit actúa un poco más lenta.

@Kudo ¿También midió el tiempo de inicio de la aplicación y el uso de memoria? Siempre he asumido que estas dos métricas serían mejores sin JIT. Dado que la mayoría de las aplicaciones son pesadas en la interfaz de usuario, no estoy seguro de que JIT sea de mucho beneficio en las aplicaciones del mundo real, por lo que me encantaría tener JIT deshabilitado si mejora el inicio y el uso de la memoria. También tengo curiosidad por saber si JSC tendrá una huella de disco más pequeña sin JIT.

@Kudo
Arreglar __clear_cache como lo hizo en estas compilaciones de prueba definitivamente está mejorando la situación, pero hay un efecto secundario de la corrección o una interacción más compleja que aún no es obvia. Dicho esto, no he podido volver a bloquear la aplicación de prueba -fix-clear-cache-dfg . Puede ser que como dice @tuncaulubilge , el comportamiento dependa de la presión de la memoria y / u otros factores.

Desactivar JIT por completo parece ser la opción "libre de fallas", no he notado degradaciones en el rendimiento con esta opción, por lo que sería la opción "segura".

@Kudo para aclarar, he estado comparando React-Native 0.58.6 (sin ningún jsc personalizado instalado) vs 0.59.8 con @kudo-ci/jsc-android@241213-no-jit .

No he realizado ninguna medición, pero la mejora del rendimiento es muy notable. Esperaría que la versión no jit sea ​​un poco más lenta que la [email protected] como mencionaste, pero eso es ignorable en comparación. Sugeriría ir con la versión no-jit como la opción predeterminada también, ya que las mejoras de estabilidad superan en gran medida la mejora menor de rendimiento que obtendría de jit.

Estamos utilizando Expo v32 para crear nuestra aplicación y estamos viendo este error en todas las versiones y dispositivos de Android.

@ tido64 TTI no tiene muchas diferencias. El tamaño binario se reduce alrededor de 1 MB desde la versión no_dfg. La memoria se reduce aproximadamente en un 48%.
Envié un PR para deshabilitar JIT totalmente y hay un resultado de medición.
https://github.com/react-native-community/jsc-android-buildscripts/pull/108

@timhatch Es bueno escuchar que arreglar __clear_cache ayuda un poco.
Todavía dudo que la causa raíz sea de big.LITTLE, pero todavía no encontré otro código JSC que cause problemas.
Tanto Samsung S5 como S7 son big.LITTLE y los dos conjuntos de CPU tienen diferentes tamaños de línea de caché.
Quizás esa sea la razón por la que no pude reproducir el bloqueo en Samsung Note 5, que el tamaño de la línea de caché de sus dos conjuntos de CPU son 64B.
No estoy seguro de si es posible que el programador del sistema operativo y JSC hagan la transición entre una CPU grande <-> LITTLE en tiempo de ejecución.
Si es cierto, el problema puede ocurrir especialmente en ese momento.

@tuncaulubilge Eso es curioso para mí.
Puede verificar mi PR , la versión no-jit es más lenta que el stock RN058 JSC.
Eso también es lo que sentí durante la medición.
Tal vez los puntos de referencia son casos extremos y no son como solía ser una aplicación RN.
Por cierto, vi que el tamaño binario y el tamaño de la memoria se reducen con respecto a la versión sin jit.
Estos dos beneficios y sin accidentes son más razonables para mí.

Este código salva vidas

@RomanovYurii Cuando eliminamos los filtros ndk de 64 bits "arm64-v8a", "x86_64" de ndk abiFilters en el bloque defaultConfig de build.gradle proporcionando solo soporte de 32 bits. El bloqueo ha desaparecido, pero según el mandato de soporte de 64 bits de Google, esto debe solucionarse con soporte ndk de 64 bits.

25060

@dishantwalia @Kudo disabled JIT funciona para mí en 64 bits y no he visto ningún problema de rendimiento hasta ahora.

Esta esencia funcionó para mí https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Queridos,

Hemos publicado el JSC no-JIT en jsc-android npm y revisé mi esencia anterior para usar jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Con suerte para solucionar todos los problemas de bloqueo.
Si no hay una caída significativa del rendimiento, propondremos la versión sin JIT como la versión @latest oficialmente y enviaremos un PR para que se incorpore en la RN más reciente.

Queridos,

Hemos publicado el JSC no-JIT en jsc-android npm y revisé mi esencia anterior para usar jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Con suerte para solucionar todos los problemas de bloqueo.
Si no hay una caída significativa del rendimiento, propondremos la versión sin JIT como la versión @latest oficialmente y enviaremos un PR para que se incorpore en la RN más reciente.

Gracias @Kudo disable-

¡Gracias @Kudo por todo el trabajo duro! 241213.2.0 parece haber resuelto los fallos por nosotros. Desafortunadamente, el impacto en el rendimiento es bastante significativo. En dispositivos de gama baja en algunas de nuestras pantallas más ocupadas, hemos visto js fps disminuir en un 20-30%.

También puedo confirmar que los fallos han desaparecido, pero también estamos viendo un rendimiento bastante bajo en los dispositivos de gama baja. Debo decir que es extremadamente decepcionante considerando que hemos estado esperando actualizar a RN58 / RN59 para el JSC más moderno.

@kudo en el peor de los casos, el jit solo debe desactivarse para la versión de 64 bits, solo los dispositivos con capacidad de 64 bits se bloquean

@yenda, si esa compilación se convierte en la solución, sería bueno tener esa opción, sí. No estoy seguro de lo difícil que sería. Con suerte, eso no significaría enviar dos versiones del JSC

@benoitdion @ItsNoHax ¿Puede enumerar los dispositivos específicos en los que observó un rendimiento deficiente? ¡Gracias!

Probado en un Nexus 5 y Samsung Tab E, entre otros.

Para cualquier empleado de Google que esté actualizando su proyecto RN a 59.x, asegúrese de que en android/app/build.gradle -> android {defaultConfig {versionName}} no coincida con su versión especificada de react-native-code-push.

Luché alrededor de tres días por el mismo problema y luego descubrí que mi proyecto React Native actualizado en v59.3 se estaba actualizando mediante code-push que tiene React Native v54.7

Este no debe ser el caso del 90% de la población. Pero para algunos como yo, puede ahorrar tiempo.

Después de eso gracias a @Kudo. Se corrigieron los problemas de bloqueo.

Huawei Honor 8X también tiene este problema

También puedo confirmar que los fallos han desaparecido, pero también estamos viendo un rendimiento bastante bajo en los dispositivos de gama baja. Debo decir que es extremadamente decepcionante considerando que hemos estado esperando actualizar a RN58 / RN59 para el JSC más moderno.

Igual que aquí. El antiguo RN en Android era lento y fallido, el nuevo RN es rápido y fallido y con esta solución, el nuevo RN es estable y lento. Parece que no podemos tenerlo todo en Android. 🙈

Queridos,

Lamento mucho que el rendimiento haya actuado mal para la versión sin JIT.
Y lo siento, no tengo soluciones en este momento.
Es difícil para mí solucionar un problema tal que no pude reproducir.
Con suerte, alguien de la comunidad podría ayudar a resolver el problema.

JSC para RN es OSS en https://github.com/react-native-community/jsc-android-buildscripts.
Es compatible para habilitar la compilación de depuración al descomentar la línea en https://github.com/react-native-community/jsc-android-buildscripts/blob/master/scripts/start.sh#L10.
Adjuntando gdb o lldb para depurar de forma nativa, tal vez haya alguna pista.
El bloqueo podría violar algún RELEASE_ASSERT en https://trac.webkit.org/browser/webkit/releases/WebKitGTK/webkit-2.22.6/Source/JavaScriptCore/jit/JITOperations.cpp#L1067 , pero no estoy seguro de cómo va el problema al Estado.

Gracias por todo su trabajo en esto y jsc-android-buildscripts @Kudo. ¡Ha sido increíble seguir tu progreso! ¿Hay algo que nosotros (la comunidad que está viendo este problema) podamos hacer para ayudar? Creo que @tuncaulubilge tenía un caso de reproducción en su mayoría estable.

¿Quizás el equipo interno react-native de facebook tiene expertos en jsc?

Acabo de enfrentar este problema, solo ocurre en DISPOSITIVO REAL, LENOVO A701a48, EJECUTANDO ANDROID 6.
eliminando "arm64-v8a", "x86_64" de

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

lo resolvió, pero me sentí un poco hack-y.

Espero que haya una actualización del equipo de RN pronto :(

Queridos,

Este es probablemente mi último intento: usar la versión más reciente de WebKit.
@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg se basa en WebKitGTK 2.24.2, con JIT de referencia pero sin DFG JIT.
Un cambio notable es que el WebKit más nuevo cambió el formato de código de bytes JIT.
El JIT de x86 no es compatible y el soporte JIT de armeabi-v7a es de la comunidad (Gracias Igalia).
Dado que el bloqueo ocurre solo en arm64, vale la pena probar la nueva versión.

Los pasos detallados para integrar esta versión se encuentran en https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md.
El cambio notable es que 241213 -> 245459 de la versión JSC anterior y asegúrese de tener 245459.9000.0 en el registro de adb.
Ayude a verificar este JSC experimentado.
Ojalá tengamos suerte esta vez. 🤞

@benoitdion gracias por tu ánimo ❤️

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

Puede confirmar que el bloqueo que estaba ocurriendo con RN v0.59, al usar el JSC anterior, ha desaparecido. Probado en Google Nexus 6, otros se confirmarán después del lanzamiento.

¡¡Gracias!!

@Kudo Puedo confirmar que @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg funciona para mí. No se produjo ningún bloqueo en el Samsung Galaxy S7 SM-G930FD que ocurría antes con RN v0.59 y se ha solucionado con no-jit o jsc-android v241213.2.0 .

Todavía no he tenido la oportunidad de integrar esta nueva compilación ya que tengo otros hitos del proyecto que se interponen en el camino, pero planeo hacerlo tan pronto como estos estén fuera del camino.

Las compilaciones no-dfg originales de @Kudo arreglaron el 99% de los bloqueos que había visto y, aunque pude estimular un solo bloqueo, no pude repetirlo.

Creo que @tuncaulubilge pudo reproducir bloqueos con las compilaciones no-dfg , por lo que sería interesante ver qué hace con esta nueva compilación.

@rimzici @dishantwalia @timhatch Gracias por tu ayuda.

@tuncaulubilge Si tiene tiempo disponible, ¿podría ayudarnos a verificar la última versión experimentada?
IIRC, solo tú y @timhatch informaron fallas de " 241213 -fix-clear-cache-no-dfg" la última vez.
Ojalá podamos solucionar los fallos con la versión actualizada.
Gracias.

@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
tiene este problema después de integrar @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg en ZTE Blade, Samsung S8, OnePlus 6. ¡Solo en Motorola Z2 Android 7.1.1 comenzó a compilar!

@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
tiene este problema después de integrar @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg en ZTE Blade, Samsung S8, OnePlus 6. ¡Solo en Motorola Z2 Android 7.1.1 comenzó a compilar!

Esto parece estar relacionado con realm , consulte https://github.com/realm/realm-js/issues/2261#issuecomment -468691502
https://github.com/realm/realm-js/issues/2221

@Kudo Una vez más, ¡gracias por el gran trabajo! Desafortunadamente, me mudé a un proyecto nuevo y ya no tengo acceso al proyecto anterior. Intentaré comunicarme con mis antiguos compañeros de equipo y conseguir a alguien que pruebe esto.

Tuvimos fallas especialmente en reactRootView.unmountReactApplication , lo que desencadena la recolección de basura, lo que provoca fallas ocasionales. Es posible que pueda reproducirlo con una aplicación de muestra, creando y destruyendo 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
tiene este problema después de integrar @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg en ZTE Blade, Samsung S8, OnePlus 6. ¡Solo en Motorola Z2 Android 7.1.1 comenzó a compilar!

Esto parece estar relacionado con realm , verifique realm / realm-js # 2261 (comentario)
reino / reino-js # 2221

¡Muchas gracias! Solo tuve que actualizar reino a 2.28.
@Kudo gracias especiales. ¡Mi aplicación ya funciona correctamente!

@Kudo He reconstruido una versión de una aplicación previamente afectada con la misma configuración de compilación que en las pruebas anteriores pero usando @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .
No hay bloqueos ni bloqueos hasta ahora: veré si puedo estresar la aplicación durante el fin de semana e informar si encuentro algún problema.

@timhatch Muchas gracias y tómese su tiempo durante el fin de semana.
Cruzar los dedos para escuchar sus buenas noticias la próxima vez.

No puedo construir con el parche. Recibo el siguiente error del FBSDK:

`` ``
Tarea: react- native- fbsdk: compileReleaseJavaWithJavac FAILED
/ Usuarios / waltermonecke / Documentos / Código / React-Native2 / moodPixel / node_modules / react-native-fbsdk / android / src / main / java / com / facebook / reactnative / androidsdk / FBAppEventsLoggerMod
ule. java: 209 : error: no se puede encontrar el símbolo
@ReactMethod (isBlockingSynchronousMethod = true)
^
símbolo: método isBlockingSynchronousMethod ()
ubicación: @interface ReactMethod
Nota: algunos archivos de entrada utilizan o anulan una API obsoleta.
Nota: Vuelva a compilar con -
Nota: /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java utiliza operaciones no controladas o inseguras.
Nota: Vuelva a compilar con -
1 error

FALLO: la compilación falló con una excepción.
`` ``

@wmonecke El problema me parece extraño. No toqué ningún código Java ni dependencias de Gradle en JSC AAR.
¿Podría comprobar el problema o describir brevemente cómo se aplica el parche?
Supongo que accidentalmente usas la antigua dependencia de RN y
podría verificar por ./gradlew :app:dependencies | grep 'com.facebook.react:react-native:' (asegúrese de que la versión RN devuelta sea la que esperaba).

No puedo construir con el parche. Recibo el siguiente error del 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 , debe agregar el repositorio de maven (react-native y kudo ci) para que se compile
maven {
// Todo React Native (JS, fuentes Obj-C, binarios de Android) se instala desde npm
url "$ rootDir /../ node_modules / react-native / android"
}

maven {
// Repositorio local de Maven que contiene AAR con biblioteca JSC creada para Android
url "$ rootDir /../ node_modules / @ kudo-ci / jsc-android / dist"
}

@Kudo No hay problemas con @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Ninguna aplicación se cuelga o falla.

@Kudo No hay problemas con @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Ninguna aplicación se cuelga o falla.

@Kudo Por favor introduzca esa corrección en jsc-android-buildscripts y publique una versión. Entonces podemos implementar esto en nuestras aplicaciones de producción https://github.com/react-native-community/jsc-android-buildscripts.

@timhatch ¡Impresionante! Especialmente gracias por su verificación. Impulsará los cambios de JSC en RN pronto.

@dishantwalia Sí, en curso. Gracias.

Gracias @Kudo por todo tu trabajo en esto. ¿Puede usted (o alguien más que sepa lo que está sucediendo) guiarme en la dirección correcta para implementar esta solución (me doy cuenta de que es un trabajo en progreso)?

Actualmente estoy en RN 0.59.9. Con los cambios que se están implementando, ¿estará disponible una versión actualizada de RN algo como 0.59.10 o debería instalar jsc-android-buildscripts como un paquete de terceros e implementar para 0.59x según la documentación?

@Kudo Tampoco hay problemas con tu última versión. ¡Buen trabajo! 💪

Gracias @Kudo , tengo la misma pregunta que @jacquesdev está haciendo 0.59.10 o jsc-android-buildscripts ?

@Kudo @dishantwalia
¡Gracias! Solo me quedaba:
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" }

dentro de build.gradle

@Kudo, lamentablemente, el problema sigue ahí (Galaxy S7, Android7). He probado @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .

También probé la versión sin JIT, que no ayudó. No logré que la versión "JavaScriptCore" se imprima en adb logcat utilizando el grep que proporcionó, ni vi ninguna mención de JavaScriptCore en el registro al buscar manualmente.

Puedo reproducir el accidente con bastante frecuencia. No siempre choca en el mismo lugar.

Aquí está el error (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>

El backtrace no dice nada significativo.

También mencionaré que no tengo Android7 oficial en mi Galaxy S7 porque era imposible degradar desde Android8 (no podía producir el problema con Android8), así que tuve que encontrar una rom personalizada que fuera compatible con Android7.

Estoy investigando la posibilidad de intentar compilar mi propia versión de depuración de jsc-android usando su última confirmación en jsc-android-buildscripts, pero me llevará un tiempo.

Creo que estamos teniendo el mismo problema.

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

Por versión de Android:

Versión | Número | Por ciento
- | - | -
Android 7.0 | 66 | 100,0%

Por dispositivo:

Dispositivo | Número | Por ciento
- | - | -
hero2lte | 26 | 39,4%
herolte | 24 | 36,4%
heroltebmc | 16 | 24,2%

También he tenido el bloqueo del Galaxy S7 después de actualizar RN de 0.58.6 a 0.59.9.

La versión npm actual de jsc-android aún hace que la aplicación se bloquee, pero el uso de @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg y la versión JSC 245459.9000.0 solucionó el bloqueo para mí en S7.

@ChrisEelmaa El registro "JavaScriptCore.Version" en adb logcat es una forma de confirmar para elegir la versión JSC correcta.
Debido a que RN 0.59 tiene libjsc.so incorporado y pickFirst '** / libjsc.so' no es confiable en mi opinión.

Una forma alternativa de confirmar la versión JSC sería seguir los pasos:

1. descomprimir /path/to/app.apk
2. cadenas jni / arm64-v8a / libjsc.so | grep -C 1 JavaScriptCore.Version

La salida debería ser algo como:

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

@Kudo gracias por tu solución, parece evitar que ocurra el infierno.

Mis 2 centavos allí: no tengo una carpeta jni sino una lib uno en su lugar, así que usando este comando para verificar la versión después de descomprimir:

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

Gracias @Kudo

Anteriormente tenía react-native 0.58.3, veo que la gente menciona 0.59 todo el tiempo, así que decidí actualizar también. La combinación de tener 0.59.0 y @ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg pareció hacerme el truco.

Ya no puedo producir el accidente.

¿Alguien sabe si habrá una solución para este problema en la próxima versión de RN?

¿Alguien sabe si habrá una solución para este problema en la próxima versión de RN?

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

@kristerkari
Solo para confirmar los pasos que siguió.

Siguió las instrucciones aquí, https://github.com/react-native-community/jsc-android-buildscripts#for -react-native-version-059

Pero intercambió en lugar de agregar "jsc-android": "241213.x.x", , agregó @kudo-ci/jsc-android": "^245459.9000.0 a su package.json? ¿Hiciste otros cambios?

Por ejemplo, veo que en build.grade, debe agregar implementation "org.webkit:android-jsc:r241213" , ¿esa línea también tiene que cambiar y, en caso afirmativo, cuál debería ser?

Sigo recibiendo el error de compilación Could not find org.webkit:android-jsc:r241213. o Could not find org.webkit:android-jsc:r245459.9000.0. Así que supongo que mi problema es usar la referencia incorrecta allí, pero no puedo decir cuál debería ser.

@jacquesdev siga los pasos de esta guía: https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md

Queridos,

Solo para actualizar eso con la ayuda de @kmagiera , mi parche se ha publicado como ' [email protected] '.
Envié https://github.com/facebook/react-native/pull/25426 para tener el JSC actualizado en RN.
Y @kelset también lo tiene en RN 0.60 RC.
Ojalá podamos finalmente solucionar y cerrar este problema.
Grita a la gente aquí especialmente por la ayuda para verificar mis versiones experimentadas de un lado a otro.
¡Somos la así llamada comunidad RN!

¡Gracias @Kudo! ¿Tiene alguna idea de si esto tiene alguna posibilidad de hacer una versión 0.59.x, o es probable que sea solo en 0.60?

Sería fantástico si pudiéramos conseguirlo en 0.59.x
0.60 tiene muchos cambios importantes con AndroidX y bibliotecas externas.

+1 para nosotros, ponerlo en 0.59.x resolvería muchos problemas para nuestro
aplicaciones.

Realmente no quiero entrar en 0.60 debido a la compatibilidad con Android X en
bibliotecas hasta ahora.

El pickFirst para JSC no nos ha funcionado, debe ser una de nuestras bibliotecas nativas
causando un problema, pero parece que siempre elige la versión interna rn.
(Sin embargo, el proyecto limpio funcionó, por lo que debe ser uno de nuestros departamentos lo que lo causó)

Iglesia

El sábado 29 de junio de 2019 a las 19:35 Anurag Dadheech, [email protected]
escribió:

Sería fantástico si pudiéramos conseguirlo en 0.59.x
0.60 tiene muchos cambios importantes con AndroidX y bibliotecas externas.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ25TBIFBOI3QWMSPXLP46TN3A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXG43VMDVN5W63 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AABPHZ2D5WUEM4S3242ZTYTP46TN3ANCNFSM4HC77RAQ
.

Hola, ¿puedo saber dónde agregar este "@ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg "?

Hola @Kudo, ¡ gracias por tu increíble trabajo!

En el WebKit antiguo sin DFG JIT, todavía se producen bloqueos, pero el WebKit 2.24.2 más nuevo sin DFG JIT parece solucionarlo. Me pregunto si vale la pena probar este nuevo WebKit con DFG JIT habilitado para permitir el mayor rendimiento posible si funciona.

Estoy de acuerdo con algunos comentarios antes de que sea mejor tener un 0.59.10 con esta solución porque va a ser más difícil actualizar a 0.60 @Kudo @kelset @grabbou @turnrye

Tengo el mismo problema aquí,

No podemos actualizar a 0.60 porque react-native-maps aún no es compatible con AndroidX, no podemos enviar nuestras actualizaciones a 0.59.X porque S7 y S7 plus fallan.

Este es realmente un problema para las empresas que dependen de react-native

¿Existe alguna solución para esto?

Estoy de acuerdo con @adnkh , no podemos actualizar a AndroidX ahora, pero tenemos que resolver las fallas de 0.59.

No es necesario actualizar a 0,60 para consumir la corrección. Debería poder seguir las instrucciones en https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. La versión que desea instalar es 245459.0.0 o superior.

Hola @benoitdion ,

Sí, es posible consumir aunque no esté en la biblioteca principal, de hecho, seguí estas instrucciones https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 . Y funcionó

Pero no creo que esta sea una solución permanente y ordenada debido a las muchas cosas que necesita agregar a su proyecto de Android, creo que una revisión en el RN principal sería más conveniente desde el punto de vista del desarrollador y resuelve muchos problemas de bloqueo. en aplicaciones de Android

No es necesario actualizar a 0,60 para consumir la corrección. Debería poder seguir las instrucciones en https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. La versión que desea instalar es 245459.0.0 o superior.

@benoitdion sí, pero es una solución, una corrección oficial publicada como 0.59.10 sería mejor.

Gracias @Kudo
Use @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg redujo la mayoría de los bloqueos
Pero todavía hay algunos fallos en la producción.

xiaomi MIX 3 XiaoMi / MIUI Android 9, nivel 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, nivel 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, nivel 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>

👋 todos.

Los escuchamos a todos, y debido a los problemas que muchos de ustedes están teniendo, hicimos una última versión del parche 0.59.10 para brindarles la nueva versión de JSC.

Muchísimas gracias a @Kudo por su trabajo en la

No haremos otras versiones 0.59 en el futuro previsible, ya que es un trabajo desafiante e incluso más difícil porque también estamos trabajando en 0.60 (¡que también tendrá el nuevo JSC!).

Voy a cerrar esto ya que se ha abordado el problema principal, pero sugeriría abrir uno nuevo para otros bloqueos que pueda estar experimentando después de 0.59.10.

Noticias excelentes !!

Gracias a todos, especialmente @kudo !!

El martes, 2 de julio de 2019, 12:29 Lorenzo Sciandra, [email protected]
escribió:

👋 todos.

Los escuchamos a todos, y debido a los problemas que muchos de ustedes están teniendo,
hizo un último lanzamiento de parche 0.59.10 para proporcionarle la nueva versión de
el JSC.

Muchas gracias a https://github.com/Kudo por su trabajo en
portando esto a 0.59.

No haremos nuevos lanzamientos 0.59, ya que es un trabajo desafiante e incluso
más difícil porque también estamos trabajando en 0.60 (que tendrá el nuevo JSC
¡también!).

Voy a cerrar esto ya que se ha abordado el problema central principal, pero
sugiera abrir uno nuevo para otros bloqueos que pueda estar experimentando
después de 0.59.10.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZZG2Z764HFNPJB7UVTP5M325A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXWHJWWK3TUL52HS4DFVREXWHG43WZVMV ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AABPHZ5PYT4F7ZZGQXZKKKLP5M325ANCNFSM4HC77RAQ
.

¡Muchas gracias por la solución! Después de actualizar react-native a la versión 0.59.10 , ¿todavía necesito implementar los pasos mencionados aquí ?

Kevin

Después de actualizar a RN 0.59.10, no es necesario seguir ninguno de los principios
instrucciones por más tiempo.

K

El miércoles 3 de julio de 2019 a las 15:42, Kevin Etore, [email protected] escribió:

¡Muchas gracias por la solución! Después de actualizar react-native a la versión 0.59.10,
¿todavía necesito implementar los pasos mencionados aquí?
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 ?

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ6H66HMI6CFMXMR4Y3P5S3DVA5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXWHG43WTZVMVDFVREXWHJDVMVD
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AABPHZ6UMO5NS4F4OZ7RWPTP5S3DVANCNFSM4HC77RAQ
.

Mi aplicación aún falla en Meizu M5s M612H Android OS 6 con RN-0.59.10. Creé un nuevo problema como sugirió @kelset .

Sigue fallando en Caterpillar S41 (Android 8.0). La solución resolvió el problema en todos los demás dispositivos. También creó un nuevo problema . Dime si esta no es la forma correcta de hacerlo.

Hola chicos
Mi aplicación también falla en algún dispositivo Android cuando se compila en 64 bits

¿Está utilizando la versión 1.1.0 del paquete react-native-elements ?
Debido a que el componente Header bloquea mi aplicación y también el componente Avatar cuando pongo el icono o título de prop

¿Alguien más puede comprobar si les pasa lo mismo?

¿Algún propietario de un s7 tuvo la oportunidad de probar este problema con Hermes?

si uso la aplicación a continuación se bloquea y es aceptada por Google Play Store
ndk {abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"}
Si utilizo la siguiente aplicación funciona pero no es aceptada por Google Play Store
ndk {abiFilters "armeabi-v7a", "x86"}

por favor que alguien me ayude a resolver

Aún falla en Moto G7 y Pixel 2 (ambos con Android 9.0) con el APK del brazo de 64 bits. Funciona bien con el APK de brazo de 32 bits.

@ afras21 : esto se debe a que el error existe en la versión de 64 bits, que Google Play Store hace obligatorio.

@jacquesdev Gracias jacq, ahora eliminaron lo obligatorio y ahora está funcionando

@ afras21, ¿quiere decir que Google ha eliminado la restricción de 64 bits de Play Store?

Tengo el mismo problema. Si actualizo mi proyecto de 0.59.9 a 0.60.4, ¿debería haber solucionado el problema?

Tengo el mismo problema. Actualmente estoy usando 0.59.9. Si actualizo a 0.60.x, ¿se resolverá el problema?

Primero, pruebe si 0.59.10 resolvió los problemas por usted.
Si no, tal vez valga la pena actualizar RN 0.60.4 y encender Hermes en su lugar.

Repitiendo lo que dijo Kudo, simplemente dando contexto y resumiendo el contenido anterior de este número (ya que probablemente sea difícil clasificar tantos comentarios en este punto):

Si tiene 0.59.9 o menos, este es un problema verificado con el JSC antiguo. Es el tema de cientos de comentarios arriba (y en otros números). El problema no es exclusivo de 64 bits, pero ocurre con mayor frecuencia con 64 bits.

0.60+ tiene varios cambios importantes, especialmente en Android.

Si no quiere pasar por eso, intente 0.59.10 ya que tiene la solución (como se describe arriba) integrada directamente en la versión / compilación, y parece solucionar el problema en la mayoría de los casos.

Todavía hay casos en los que hay problemas para ciertos teléfonos (que yo también he encontrado), consulte # 25494; si tiene esto, le sugiero que publique sus trazas de pila en ese problema abierto allí. Sin embargo, si dice que tiene 0.59.9, _probablemente_ puede solucionar su problema yendo a 0.59.10.

@MalcolmScruggs @ntorion @ harryt2
¿Lo has resuelto? Cómo resolver？ Gracias

0.59.10 no me lo resolvió. Intentaré hacer la actualización 0.60.x

@MalcolmScruggs @ntorion @ harryt2
¿Lo has resuelto? Cómo resolver？ Gracias

0.59.10 tampoco me lo resolvió. No puedo actualizar a 0.60.x porque algunas de mis dependencias no funcionarán. Consiguió compilarlo en Hermes, pero vi un gran aumento en los ANR (gracias a Dios por el lanzamiento por etapas). Todavía estoy en Play Store con la versión 0.57.8 de RN, pero ya no puedo actualizar mi aplicación debido al requisito de 64 bits. Bastante frustrado y tratando de decidir si reconstruir la aplicación completa con otro marco.

@ harryt2 @rogerkerse Gracias.
Mi situación es aún peor. La versión publicada tiene errores, así que tengo que actualizar la aplicación 64. No puedo resolver este problema en este momento. También estoy intentando flutter, pero no un reemplazo completo tan rápido.

De hecho, me tomé la molestia de cambiar React-Native a 0.60.5 y habilitar Hermes + 64-bit (lo cual fue un dolor, ya que la actualización de react-native siempre lo es) y todavía tengo estos problemas en varios teléfonos Android (incluido HUAWEI MYA-L41).

Probé casi todo lo que encontré en otros hilos sin mucha suerte, por lo que puedo decirle que el uso de React-native y Hermes no soluciona todos estos problemas.

El react-native + Hermes actualizado y de 64 bits es increíble en otros dispositivos Android en los que lo he ejecutado y nuestra aplicación nunca se ha sentido tan fluida.

Sin embargo, cada vez que pruebo en el dispositivo específico que mencioné (Huawei) se bloquea instantáneamente o después de que la aplicación está abierta durante 1-2 segundos sin un mensaje de falla específico, no tengo ningún otro dispositivo además de ese y un Huawei más nuevo ( que funciona perfectamente) así que no puedo darte más información sobre otros teléfonos.

Si alguien ha logrado algún progreso con este problema o tiene alguna idea para registrar más específicamente mis problemas, los consejos siempre son bienvenidos y estoy dispuesto a compartir cualquier información con respecto a este problema.
Gracias a las personas de este hilo por ofrecer soluciones, pero hasta ahora no hemos tenido suerte. 🙂

@YoranRoels ¿Ha intentado ejecutar una aplicación limpia creada por react-native init? Me pregunto si la falla es causada por el propio RN o por alguna biblioteca o código que haya escrito.

@armenbadalyan Gracias por la rápida respuesta.

Acabo de configurar un nuevo proyecto e intenté ejecutarlo en el dispositivo y todo parece estar bien, así que al final parece algo con mi configuración. ¿Existe una forma eficiente de depurar esto ya que mi logcat no arroja nada útil además de que com.<our_app_id> ha sido eliminado?

React Native 59.10 tampoco nos lo soluciona. La aplicación aún falla en el primer lanzamiento.

@GreanBeetle Ver https://github.com/facebook/react-native/issues/25494. 0.59.10, desafortunadamente, se sabe en este momento que no soluciona este problema en todos los casos.

La ruta más actualizada es usar (como en este hilo), 0.60+ y Hermes.

@YoranRoels Obtén la lápida del dispositivo. Ver: https://github.com/facebook/react-native/issues/24261#issuecomment -490239902

@GreanBeetle Puede usar el motor V8 en 0.59.10 para deshacerse de este problema
https://github.com/Kudo/react-native-v8

Gracias @ j-wang. @manuhook va a darle una oportunidad a tu solución.

@GreanBeetle Puede usar el motor V8 en 0.59.10 para deshacerse de este problema
https://github.com/Kudo/react-native-v8

Puedo confirmar que esto nos resolvió el problema. Las compilaciones de 64 bits con react-native-v8 en 0.59.10 ya no se bloquean y finalmente podemos enviar actualizaciones nuevamente en Google Play. ¡Gracias!

Probé el registro de lápidas que mencionó @ j-wang, pero nunca lo he usado realmente y era un archivo inmenso que era difícil de leer, después de buscar por un tiempo, realmente no parecía encontrar una causa raíz legible.

Después de seguir el consejo de @armenbadalyan , comencé a preguntarme si no era algo tonto al inicio de nuestra aplicación y, eliminé la interfaz de usuario del primer componente, noté que la aplicación se estaba ejecutando nuevamente, estable. Entonces, después de investigar más, noté que un componente específico tenía problemas en los que se representaba una imagen.

En ese componente existe la posibilidad de que pasemos null como la variable source en una react-native Image . Me tomó un tiempo buscar esto y no hay errores claros reales, pero esto finalmente solucionó todo para mí y se está ejecutando en todos nuestros dispositivos de prueba. Todavía no tengo idea de por qué no falló en nuestro otro dispositivo de prueba ...

Podría ayudar a otras personas a simplificar el primer componente de su aplicación para asegurarse de que no se bloquee en ese código.

TL; DR : Esto probablemente esté completamente fuera de tema a estas alturas, pero a quien le concierne: NO USE null COMO LA VARIABLE source DE Image , no lo hace ' t funciona en todos los dispositivos. 😅

@ harryt2 sí, yo también. Obtuve un gran aumento en ANR después de actualizar a RN 0.60. +

Un poco de ayuda para los que todavía intentan solucionar el bloqueo de inicio:

1. ejecutar adb logcat en una consola
2. espere a que se detenga el spam de la consola
3. abre la aplicación que falla en tu dispositivo
4. Detenga el adb logcat con Ctrl + c
5. desplácese hacia arriba y encuentre el accidente

No resuelve el problema, pero le permite descubrir algo más. Tengo 2 aplicaciones, una funciona bien con la de 64 bits, y la otra sigue teniendo problemas, incluso si tienen la misma configuración. Mi dispositivo que falla es un One Plus 5t (64 bit)

Acabo de ver esto en una nueva versión de nuestra aplicación, construida con RN 59.10, específicamente en un Samsung Galaxy Note9 en Android 9. ¿Alguien más está viendo un problema similar?

@msspshaw Como se mencionó anteriormente y en el otro número, sí. El nuevo JSC se bloquea o se bloquea de forma aleatoria en ciertos dispositivos Android porque se recolecta la basura de forma no determinista; luego, toda la aplicación falla.

La solución es actualizar a 0.60+ y usar Hermes, o cambiar JSC por v8.

Probé el registro de lápidas que mencionó @ j-wang, pero nunca lo he usado realmente y era un archivo inmenso que era difícil de leer, después de buscar por un tiempo, realmente no parecía encontrar una causa raíz legible.

Después de seguir el consejo de @armenbadalyan , comencé a preguntarme si no era algo tonto al inicio de nuestra aplicación y, eliminé la interfaz de usuario del primer componente, noté que la aplicación se estaba ejecutando nuevamente, estable. Entonces, después de investigar más, noté que un componente específico tenía problemas en los que se representaba una imagen.

En ese componente existe la posibilidad de que pasemos null como la variable source en una react-native Image . Me tomó un tiempo buscar esto y no hay errores claros reales, pero esto finalmente solucionó todo para mí y se está ejecutando en todos nuestros dispositivos de prueba. Todavía no tengo idea de por qué no falló en nuestro otro dispositivo de prueba ...

Podría ayudar a otras personas a simplificar el primer componente de su aplicación para asegurarse de que no se bloquee en ese código.

TL; DR : Esto probablemente esté completamente fuera de tema a estas alturas, pero a quien le concierne: NO USE null COMO LA VARIABLE source DE Image , no lo hace ' t funciona en todos los dispositivos. 😅

+1 funciona para mí. Tuve los mismos problemas. ¡Gracias!

También vea cómo sucede en un Samsung Galaxy S7 IO-IL 086 en Android 7.0 RN 0.59.10

@BracketMan ¿Estás usando V8 en lugar de JSC?

@EmilScherdin ahhh no, no lo soy. Lo intentaré e informaré gracias.

@EmilScherdin Puedo confirmar que ejecutar en V8 en RN 0.59.10 está funcionando para mí, no más fallas.

¡Gracias!

Experimentamos el mismo problema en RN 0.59.10 con v8. Veo que JIT no está deshabilitado para arm64-v8a y en dispositivos con esta arquitectura tenemos fallas.

@mmamoyco ¿Tiene el stacktrace del accidente de V8?

@Kudo Sí, tengo el registro de

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 :: plataforma :: 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 pc 000000000001f2f4 /system/lib64/libc.so (__start_thread + 68)

Tuvimos este problema exacto en 0.59.1 y pudimos solucionarlo haciendo lo siguiente:

⛄️ Estas instrucciones no son las mismas que en el archivo README de jsc-android . Hemos modificado los números de versión y algunos significantes. La versión canary de jsc no soluciona el problema. Es la versión posterior a jsc-android @ canary que se necesita, consulte: Este parche para la corrección original que se fusionó en el repositorio react-native. Gracias a @ ravali121 por ayudar a resolver esto.

1. Agrega jsc-android a la sección "dependencias" en tu package.json :

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

luego ejecute npm install o yarn (dependiendo del cliente npm que use) para que la nueva dependencia se instale en node_modules

1. Modifique el archivo android/build.gradle para agregar el nuevo repositorio local de maven empaquetado en el paquete jsc-android a la ruta de búsqueda:

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. Actualice el archivo build.gradle su aplicación ubicado en android/app/build.gradle para agregar la dependencia JSC. Asegúrese de que la dependencia sea anterior a la dependencia de 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. Actualice el archivo build.gradle su aplicación ubicado en android/app/build.gradle para usar la primera biblioteca JSC coincidente.

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

¿Alguien podría ayudar a responder esta pregunta?
https://github.com/react-native-community/jsc-android-buildscripts/issues/127

NO USE null COMO LA source VARIABLE DE Image , no funciona en todos los dispositivos. 😅

Odio solo citarlo, pero casi pierdo su solución en el ruido de este hilo. ¡¡Muchas gracias @YoranRoels !! ¡Esto salvó el día!

Encontré un sitio web de prueba de máquina real en línea , allí elegí GALAXY S7 Edge y el sistema operativo Android 7.0, desafortunadamente no sucedió un bloqueo, y trato de usar el conjunto de métodos source variable de Image a {null} y {{ uri: null }} pero todavía no se bloquea, Horrible, ni siquiera sé cómo sucedió, ¿Alguien puede ayudarme?

Tuvimos este problema exacto en 0.59.1 y pudimos solucionarlo haciendo lo siguiente:

⛄️ Estas instrucciones no son las mismas que en el archivo README de jsc-android . Hemos modificado los números de versión y algunos significantes. La versión canary de jsc no soluciona el problema. Es la versión posterior a jsc-android @ canary que se necesita, consulte: Este parche para la corrección original que se fusionó en el repositorio react-native. Gracias a @ ravali121 por ayudar a resolver esto.

1. Agrega jsc-android a la sección "dependencias" en tu package.json :

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

luego ejecute npm install o yarn (dependiendo del cliente npm que use) para que la nueva dependencia se instale en node_modules

1. Modifique el archivo android/build.gradle para agregar el nuevo repositorio local de maven empaquetado en el paquete jsc-android a la ruta de búsqueda:

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. Actualice el archivo build.gradle su aplicación ubicado en android/app/build.gradle para agregar la dependencia JSC. Asegúrese de que la dependencia sea anterior a la dependencia de 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. Actualice el archivo build.gradle su aplicación ubicado en android/app/build.gradle para usar la primera biblioteca JSC coincidente.

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

¡Eres un salvavidas! ❤️ He estado buscando su respuesta durante tres días para pegar ese código y cambiar la versión de jsc-android exactamente a la que ha mencionado. ¡Y ahora está funcionando! Ocurrió un error cuando actualicé la versión RN de 0.59 a 0.60. La aplicación se rompió solo para Android, iOS estaba bien. Lo más extraño fue que la aplicación se compiló correctamente, por lo que todo se veía genial, pero cuando se lanzó, se bloqueó de inmediato.