Obrigado por enviar seu problema. Você pode dar uma olhada em sua descrição e verificar se o modelo de problema foi preenchido por completo?

👉 Clique aqui se quiser dar uma outra olhada no modelo de problema de Relatório de Bug.

Obrigado por enviar seu problema. Você pode dar uma olhada em sua descrição e verificar se o modelo de problema foi preenchido por completo?

👉 Clique aqui se quiser dar uma outra olhada no modelo de problema de Relatório de Bug.

Atualizada

Captura de tela do erro Logcat para referência

publicando compilação de divisão de 64 bits, também estou recebendo esta falha no lançamento no Galaxy S7 e Galaxy S7 Edge com Android 7.0
sinais vitais do Android mostrando:
sinal 11 (SIGSEGV), código 1 (SEGV_MAPERR) WTFCrash
backtrace:
# 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 pc 000000000019e27c

no Crashlytics para os dispositivos que estou recebendo:
Exceção fatal: com.facebook.react.common.c
Violação invariável: retomando o trabalho ainda não implementado.

a solução alternativa de fornecer apenas compilação de 32 bits é resolver isso por agora

Estou vendo exatamente os mesmos erros de @nadavmos no Galaxy S7 executando o Android 7.0. O aplicativo está travando na inicialização

Estou vendo exatamente os mesmos erros de @nadavmos no Galaxy S7 executando o Android 7.0. O aplicativo está travando na inicialização

@nsantacruz você também está usando a navegação

@nadavmos , não estou usando react-navigation . Este pode muito bem ser o mesmo problema do # 24260, já que esse problema também está afetando 0,59 com Samsung S7 no Android 7.0

@nadavmos O travamento não está relacionado a react-navigation , na verdade, o aplicativo está travando em um novo Projeto RN criado via init do react-native.

@hramos @mkonicek A partir de agora podemos concluir que este parece ser um problema com a última versão RN 0.59, afetando as compilações do Android em execução em Samsung S7 , S7 Edge após fornecermos suporte para arm64-v8a , x86_64 , removê-los de build.gradle não trava o aplicativo, o que pode afetar potencialmente os aplicativos que vão ao ar após 1 August 2019 acordo com a política de suporte de 64 bits do Google Play. Gostaríamos de chamar a atenção para isso, por favor?

Também acontecendo em 0.58.5. Galaxy S7. Android 6.0. Configurá-lo para 32 bits também não está funcionando.

Estamos observando as mesmas falhas em compilações de 64 bits do RN 0.59.4 em um Galaxy S7 executando o Android 7.0. Infelizmente não temos acesso a esse modelo de dispositivo. Funciona bem em todos os nossos.

Tendo o mesmo problema com o dispositivo Huawai P9 no seguinte ambiente:

  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 é o rastreamento de pilha do Crashlytics que obtemos:

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

Tendo o mesmo problema com o Samsung Galaxy S7, no 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)

~ Adicionar isso ao seu android/app/build.gradle ~ pode corrigir ~ (não resolveu): ~

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

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

Obrigado por tentar ajudar, mas a solução não nos ajudou.

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

Adicionar isso ao seu android / app / build.gradle pode corrigir:

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
Testando isso agora.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/facebook/react-native/issues/24261#issuecomment-483728028 ou ignore o tópico https://github.com/notifications/unsubscribe-auth/ AEO_1BMzddSncn2DtQeDcx_y1KIz0ZSGks5vhfaJgaJpZM4cX_xB .

Adicionar isso ao seu android/app/build.gradle pode corrigir:

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

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

Estou testando isso agora.

@AndrewJack estava funcionando para você?

Adicionar isso ao seu android/app/build.gradle pode corrigir:

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

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

Estou testando isso agora.

Infelizmente nós já tínhamos aqueles lá.

Retiramos nossas compilações de 64 bits da Play Store. Isso pode não estar relacionado ao travamento na compilação de 64 bits, mas os dispositivos Galaxy S7 que executam a compilação armeabi-v7a agora estão travando muito conforme a seguir. Imediatamente após a inicialização.

Realmente me perguntando o que há de tão diferente no S7 em comparação com outros 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 Não funcionou, pensei que corrigir a configuração jsc-android-buildscripts poderia funcionar.

Estou recebendo a mesma exceção e não pode ser detectada pelo manipulador de exceção não capturada. Em meu aplicativo Android, experimentei este código:

Thread.setDefaultUncaughtExceptionHandler(...);

com handler, que apenas grava o nome da exceção no console e retorna o controle ao manipulador padrão, mas esse código não foi executado antes da falha do aplicativo.

Eu estava tentando investigar por que o Crashlytics não registra essas exceções. Talvez seja esse o motivo ... Lembro-me de que uma ou duas vezes vi travamentos nativos em meu console de malha, então o crashlytics é capaz de registrar travamentos nativos, mas de alguma forma não neste caso.

@SpertsyanKM O travamento ocorre no nível ndk. Você não verá a falha no console do firebase, a menos que adicione a biblioteca Crashlytics NDK. https://docs.fabric.io/android/crashlytics/ndk.html

Como você descobriu, Thread.setDefaultUncaughtExceptionHandler só detectará exceções Java.

Eu atualizei para RN 0.59.5 hoje e o travamento ainda acontece. Este problema ainda não foi corrigido.

Olá a todos, tenho o mesmo problema em 0.59.5, remova android: screenOrientation = "portrait" em AndroidManifest.xml. Funciona para mim.

@Jeijie Eu já não tinha isso aí, mas travou mesmo assim.

mesmo problema no REDMI NOTE 4X Android 7.0 e 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]

O mesmo problema no Galaxy S7 Edge / Android 7.0 e com três versões diferentes do React-Native: 0.58.4, 0.58.5 e 0.59.5.
A falha não foi detectada em outros dispositivos Android.

A única solução para evitar esse problema atualmente é construir o aplicativo apenas em 32 bits. Mas o problema precisa ser corrigido para o primeiro de agosto porque a Play Store não aceitará mais apenas aplicativos de 32 bits.

Experimentando o mesmo, confinado ao Galaxy S7 com Android <= 7.0 (não 8.0). Acontece desde que habilitamos o suporte a 64 bits.

Em nossa configuração padrão do gradle, nem mesmo suportamos 64 bits e mesmo assim os travamentos acontecem.
`` `
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 
}```

Mais uma vez, percebi que o problema também ocorre com alguns dispositivos Mediatek
Alcatel A5 (ELSA6)
Alcatel 1x / TCL L9 (U5A_PLUS_4G)
Alguns outros dispositivos com SoCs MediaTek com suporte x64

Oi. Nós descobrimos que:

1. ~ A correção para remover o suporte de 64 bits funciona ~ Isso só corrigiu o problema para alguns de nossos usuários
2. ~ Os usuários corrigiram esse problema por conta própria _reiniciando seus telefones_ (não há necessidade de mudar para o aplicativo de 32 bits) ~ Eles não tiveram o mesmo problema.

Posso confirmar que a remoção do suporte a 64 bits reduziu os relatórios de falhas em cerca de 90%
Isso está acontecendo com alguns dispositivos ainda. Mas a "correção" atual é o melhor que posso fazer agora

Estou recebendo travamentos no OnePlus 3 também, mas remover o suporte de 64 bits não ajuda. Estou recebendo travamentos com um projeto init de inicialização reac-nativa limpa (também em emuladores ao abrir o APK do aplicativo).

mesmo problema s7 edge android 7.0 travando em produção com divisão de pacote, outro parece estar ok
sinal 11 (SIGSEGV), código 1 (SEGV_MAPERR)
backtrace:
# 00 pc 000000000009e144
# 01 pc 00000000000a4a70

Esse problema já foi identificado no repositório do webkit. Comentei lá quando descobri esse problema meses atrás: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/327#issuecomment -436781890

Seria ótimo coordenar os esforços.

Nota: na Youi usamos RN de forma não padronizada. Construímos nosso próprio JSC de 64 bits, portanto, resolvemos esse problema muito antes, antes do 0,58.

Os fatores comuns parecem ser Android 6.0 ou 7.0 (Nível 23 e 24) e dispositivos ARM 64.
O dispositivo mais comum com essa combinação é o S7. Atualizar um S7 para Android 8 corrige o problema.

Reproduzi a falha em um emulador ARM de 64 bits do Android, mas as imagens do emulador ARM do Android são muito instáveis ​​e cheias de erros para trabalhar. Também tenho um S7 para depurar, que estou tentando fazer o downgrade para o Android 7, embora a Samsung não tenha facilitado isso.

@kmagiera & @kudo, vocês lançaram recentemente uma nova versão do JSC. Você espera que esta versão corrija este problema? O alinhamento das versões do NDK ajudaria? https://github.com/react-native-community/jsc-android-buildscripts/pull/95

@AndrewJack O novo lançamento apenas para patches de segurança WebKit e remoção de libc ++ _ shared.so para https://github.com/facebook/react-native/pull/24672. Não acho que isso resolverá os problemas de travamento.

AFAIK, existem vários tipos de falhas JSC.
Alguns são da operationLinkDirectCall conforme este problema relatado e alguns são do NPE como https://github.com/react-native-community/jsc-android-buildscripts/issues/84.
A maioria deles está relacionada ao JIT.
O caminho de falha do JIT é difícil de reproduzir internamente e também difícil de solucionar.
Tenho algumas soluções possíveis, mas não tenho certeza se elas realmente resolverão o problema de travamento.

• Uma das correções é desabilitar DFG_JIT .

• Há também uma correção de operationLinkDirectCall relacionado a upstream

• O JSC mais recente (WebKitGTK 2.24) inclui muitas mudanças JIT. Vale a pena tentar se a atualização ajudar.

IMO, se a reprodução interna não for possível, uma alternativa é entregar uma construção experimental.

Meu plano é tornar o upgrade do JSC mais fácil, simplesmente yarn add jsc-android@experiment . Isso deve acontecer em RN 0,60.
Com este mecanismo, pelo menos poderíamos estar um passo à frente para corrigir problemas de travamento.

Por outro lado, ajudaria se houvesse código e ambiente de reprodução confiáveis.
Por exemplo, há um repo de react-native-navigation. Isso ajuda muito.
https://github.com/react-native-community/jsc-android-buildscripts/issues/84#issue -407898908

O travamento acontece também no Pixel 2 com Android 9, se isso ajudar.
Existe alguma maneira de obter logs de travamento ao executar o APK? Terei prazer em ajudar a obter mais informações sobre essas falhas, mas não sei muito sobre o desenvolvimento do Android.

@quietbits , a maioria dos logs relacionados a esses problemas não são muito úteis, mas para resolvê-los:

Procure quando o travamento ocorre usando adb logcat será parecido com isto (não exatamente, já que acabei de extrair isso do topo do log, mas mostra um esforço que é o motivo pelo qual estou apontando Fora):

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

Geralmente também indica que o registro foi gravado em uma "lápide".

Para retirar a lápide, use adb bugreport ./MySuperSpecialBugReport com a última parte sendo obviamente o caminho que você deseja.

Ele vai retirá-lo como um zip e você pode descompactá-lo, navegue (na maioria dos dispositivos) para: ./MySuperSpecialBugReport/FS/data/tombstones e então você pode abrir a lápide com seu editor de texto.

Novamente, apenas devido à natureza dessas falhas, elas não são muito informativas. Pelo menos com o nosso, eles geralmente estão com mqt_js e em um endereço de ponteiro baixo. Eles também ainda ocorrem (embora cada vez menos estranhamente / imprevisivelmente) com apks de 32 bits apenas.

===

@ Kudo - definitivamente ansioso para experimentar diferentes JSCs com mais facilidade e ver o que ele faz. Este tem sido um verdadeiro ponto de dor até agora em atualizar para 0,59 com falhas super não-determinísticas e imprevisíveis (que também ocorrem em alguns dispositivos ... às vezes).

Para obter o backtrace simbolizado, usei para combinar adb logcat e ndk-stack
Por exemplo, visando RN 059 estoque JSC (que é [email protected]) e 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

Alguma atualização sobre este problema?

A remoção de 64 bits não é uma solução de acordo com Google Play 64 bit support policy. Ela pode afetar potencialmente os aplicativos que vão ao ar após 1 August 2019 . Gostaríamos de ter uma solução adequada para este problema. @hramos alguma atualização sobre isso? Chame alguma atenção.

Olá a todos, tenho o mesmo problema em 0.59.8,
Gostaríamos de ter uma solução adequada para este problema.

Oi,
Estou ajudando com o problema de travamento do JSC e também colaborando com jsc-android-buildscripts.
RN 0,59 JSC é, na verdade, de jsc-android-buildscripts .

Para solucionar o problema de travamento, precisamos do rastreamento de travamento.
Esperançosamente, siga as etapas abaixo para voltar a rastrear e postar aqui.
Eu poderia então fazer o acompanhamento para encontrar soluções potenciais.

Instale o ndk-build e execute os 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 muitos travamentos vêm do Samsung S7. Infelizmente, não tenho nenhum S7 disponível.
Esperamos obter algumas informações úteis para prosseguir com a solução de problemas.

@marlonchalegre

@Kudo Este é o log que obtive ao executar esses comandos em um novo projeto em RN 0.59.8
Eu tentei construir builds de depuração e lançamento e compilar o jsc por conta própria pelos logs parecia o mesmo em 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

Tenho um S7 em mãos e ficaria feliz em tentar executar qualquer outra coisa para tentar descobrir isso.

Minha sugestão é recompilar o JSC com o JIT desabilitado . É possível que os mecanismos de segurança do SO interfiram com os JIT's
operações de alguma forma imprevisível.

Eu reproduzi os mesmos logs de travamento que @MalcolmScruggs. Em um S7 - Android 7.1.2 - LineageOS 14.1.

No RN 0.59.8 e a versão mais recente do branch master .

Nenhuma mudança necessária para reproduzir o travamento. O modelo RN padrão dispara um travamento depois de tocar um pouco na tela.

Repo aqui - https://github.com/AndrewJack/jsc_crash/tree/rn_master_branch
Os registros de falhas estão no

Próximas etapas: construir a própria versão do JSC com JIT desativado

Se alguém tiver um S7 em uma versão mais recente do Android e quiser fazer o downgrade. Isso é o que eu fiz:

Baixe este software:

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

1. Instale a recuperação TWRP (usando odin [requer windows] ou outro método)
2. Arranque em recuperação
3. montar armazenamento
4. copiar pacote ROM & gapps do LineageOS
5. instalar imagens Flash LineageOS e gapps
6. reinicie.

Com o último react master nativo e usando fork do

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

@AndrewJack Incrível, você achou minhas construções experimentadas tão rápidas.
Agradecemos seus comentários e é bom saber que essas versões corrigiram a falha para você.

Queridos,

Eu experimentei duas versões do JSC, por favor, tente se elas podem consertar as falhas para você.
Alguns passos breves aqui:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Uma versão experimentada é desativar um tipo de JIT.
E o outro desabilita totalmente o JIT do @matthargett recomendado.
Se as duas versões corrigirem a falha para você, envie também um feedback para nós sobre o desempenho geral e TTI conforme menções em minha essência.

@Kudo Obrigado por aqueles! O que você sabe sobre GC simultâneo nessas compilações? Eu vi mencionado em algum lugar que era outra diferença em comparação com a versão de 32 bits, mas é claro que não consigo mais encontrar esse comentário. Pode ser outra coisa que vale a pena jogar com travamentos caso persistam.

@wbercx Você quer dizer GC simultâneo ou JS simultâneo (JIT simultâneo)?
Por padrão, o GC simultâneo está habilitado apenas para arm64 e x64.
O GC simultâneo pode não estar relacionado ao problema de travamento. É provavelmente sobre gerenciamento de heap e não relacionado ao JIT.

JS simultâneo está desabilitado para minhas duas compilações.
(Por padrão, ele só será ativado para ENABLE(DFG_JIT) && USE(JSVALUE64) )

BTW, JIT em JavaScriptCore é complicado e não sou um especialista nisso.
Sinta-se à vontade para apontar se eu estava errado.

@Kudo Eu tentei suas no-jit e no-dfg-jit versões experimentais JSC e não consegui reproduzir a falha. Isso parece estar de acordo com o que @AndrewJack relatou.

Eu estava tentando isso em um projeto básico, então não posso comentar sobre qualquer impacto no desempenho.

Tenho mais algumas informações, estou vendo esta falha também em:
Samsung Galaxy S7 (herolte), Android 7.0
Oppo F7 (CPH1819), Android 8.1

Também acontecendo em 0.58.5. Galaxy S7. Android 6.0. Configurá-lo para 32 bits também não está funcionando.

A falha ainda está acontecendo aqui depois de reverter para 32 bits

@MalcolmScruggs Bom saber que as duas versões experimentadas corrigem a falha para você.
Estou pensando em desabilitar DFG_JIT, pelo menos a opção JIT está alinhada com o antigo JSC.

@Kudo Você está planejando direcionar sua correção de desabilitar DFG_JIT apenas para dispositivos / CPUs afetados?

Alguém tentou com a última versão do React Native (0.59.8) que está corrigindo algumas falhas (mencionadas na nota de lançamento)?
https://github.com/facebook/react-native/releases

Alguém tentou com a última versão do React Native (0.59.8) que está corrigindo algumas falhas (mencionadas na nota de lançamento)?
https://github.com/facebook/react-native/releases

No meu caso, eu estava usando 0.59.8, desde então reverti para 0.57.8 já que nada mais parecia funcionar. Esse bug é particularmente ruim porque faz com que o aplicativo trave imediatamente após a abertura. Meu aplicativo sofreu um grande corte de cabelo nas avaliações.

Esses dispositivos têm uma falha de sinal 11, mas mostra apenas uma localização de memória.

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

Esses dispositivos parecem apresentar um erro semelhante a == / lib / arm64 / libjsc.so . Não sei o suficiente sobre o funcionamento interno para saber o que isso significa, mas espero que ajude.

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

Posso adicionar alguns dispositivos à lista de @ harryt2.

O sinal 11 travou com apenas um local de memória:

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
...
lista continua com ~ 65 dispositivos diferentes e versão do Android entre 7.0 e 9.0.

O erro nem sempre ocorre nestes dispositivos. Mas é uma preocupação real, uma vez que a taxa de falhas do meu aplicativo relatada no google play mudou de 0,16% para 1,02% após a atualização de 0,57,8 para 0,59,5.

0.57.8:

0.59.5:

Não sou um especialista em desenvolvimento Android, nem entendo de onde vem esse travamento. Posso fornecer mais alguns dados, se ajudar.

@ntorion em nosso projeto ainda vemos esses travamentos no Samsung s7 com o react-native 0.59.8, infelizmente.

Alguma solução para isso neste momento?
Eu testei em dois galaxy note 9 diferentes, cada telefone trava imediatamente

{"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 use a instrução @Kudo https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

@matpaul @Kudo posso confirmar que esta compilação experimental do js core parece resolver o problema para nós também (testado no Samsung s7).

Meus travamentos relacionados a esse rastreamento foram embora no Android quando fiz o downgrade para 0.58.6 . Estava planejando fazer o downgrade para 57.6 , mas 58.6 parece ter corrigido isso para mim (embora existam alguns outros problemas do Android que eu tive que mitigar, onde tenho que construir manualmente para o lançamento)

@Kudo

Queridos,

Eu experimentei duas versões do JSC, por favor, tente se elas podem consertar as falhas para você.
Alguns passos breves aqui:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Uma versão experimentada é desativar um tipo de JIT.
E o outro desabilita totalmente o JIT do @matthargett recomendado.
Se as duas versões corrigirem a falha para você, envie também um feedback para nós sobre o desempenho geral e TTI conforme menções em minha essência.

@Kudo eu tive duas observações aqui, como também mencionei em sua essência

• O aplicativo trava com dependência de @kudo-ci/jsc-android@241213-no-dfg-jit , ao usar um de nossos aplicativos de produção por alguns minutos.
• O aplicativo está funcionando bem com @kudo-ci/jsc-android@241213-no-jit dependency as of now e o TTI permanece o mesmo / imperceptível em relação às compilações anteriores.

Kudo, sua solicitação de pull será suficiente para corrigir isso, pois notei o travamento do aplicativo quando testado em no_dfg_jit

Mais algumas atualizações aqui:
Eu realmente duvido que o travamento nativo aconteça facilmente no S7 Edge, deve haver outros aplicativos enfrentando esses problemas.
Peguei vocês!
O serviço Google Play com API de texto apresentou esses problemas, mas nenhuma correção OSS
Mono encontrou um problema de travamento no bit.LITTLE S7 Exynos e aqui está a correção .

JavaScriptCore usou __clear_cache no ARM64Assembler.
Eu terei outra versão experimental para corrigir __clear_cache no final desta semana.

As compilações experimentadas que corrigiram __clear_cache já estão prontas.

As etapas são as mesmas de antes, mas apenas para usar diferentes dependências de npm.

1. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-dfg' e adb logcat confirmado com a versão 241213.8000.0 ( ref código-fonte aqui )
2. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg' e adb logcat confirmado com a versão 241213.9000.1 ( ref código-fonte aqui )

Lamento não poder verificar o problema da falha novamente, mas apenas para verificar as funcionalidades básicas.
Por favor, ajude a testar os dois experimentos JSC, se possível.
Muito obrigado a todos e nos deseje boa sorte desta vez.

cc @AndrewJack @MalcolmScruggs @tijs @ishantsagar @timhatch

@Kudo Agora recebi feedback sobre compilações de teste usando @kudo-ci/jsc-android@241213-fix-clear-cache-dfg e @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg .
Ambas as versões de teste parecem estar livres de falhas até agora no Samsung Galaxy S7 Edge / Android 7.0 (até agora, a combinação do problema)

@Kudo Eu experimentei @kudo-ci/jsc-android@241213-fix-clear-cache-dfg e @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg em um projeto básico executando React-Native 0.59.8 e em ambas as versões o travamento não está acontecendo. Testei em um Samsung Galaxy S7 no 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 Tentei o último @kudo-ci/jsc-android@241213-fix-clear-cache-dfg mas encontrei uma falha em um Samsung Galaxy S5 (SM-G900F), semelhante ao que tivemos com o JSC no React Native 0.59.8

A versão sem JIT estava funcionando perfeitamente ( @kudo-ci/jsc-android@241213-no-jit ) e não encontrou nenhum travamento nela, independentemente de quanto eu forcei o aplicativo ao limite. Então acho que vamos ficar com esse por agora.

Estamos usando ReactRootViews em um viewpager, portanto, criamos e destruímos instâncias nativas react com bastante frequência, e isso parece estar provocando esta falha. É provavelmente por isso que encontramos esse problema com mais frequência do que a maioria. No momento, estamos revisitando a abordagem do visualizador, mas, por enquanto, espero que este log de travamento possa ser útil. (é para a versão 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>

Infelizmente nós já tínhamos aqueles lá.

Retiramos nossas compilações de 64 bits da Play Store. Isso pode não estar relacionado ao travamento na compilação de 64 bits, mas os dispositivos Galaxy S7 que executam a compilação armeabi-v7a agora estão travando muito conforme a seguir. Imediatamente após a inicialização.

Realmente me perguntando o que há de tão diferente no S7 em comparação com outros 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)

Vimos isso internamente e percebemos que algumas de nossas propriedades de estilo estavam retornando nulo condicionalmente. Remover isso e adicionar apenas condicionalmente a propriedade de estilo corrigiu uma exceção semelhante - pode haver algo acontecendo com um tipo de módulo nativo para o seu?

@tuncaulubilge Obrigado pela informação.
Só para confirmar se Samsung S5 (SM-G900F) é arquitetura arm (não arm64), certo?
Você pode verificar por adb shell getprop ro.product.cpu.abi
Pelo seu registro de travamento, parece ser um braço.

Nesse caso, estou assumindo que a causa raiz deve ser outra história do que aqui.
Você já testou a versão no-dfg-jit, ou seja, @kudo-ci/jsc-android@241213-no-dfg-jit ou @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg ?
Essas duas versões devem ser iguais no arm32, você pode apenas testar qualquer uma.

@Kudo UPDATE

O backtrace relatado através do console do desenvolvedor para o problema original (travamentos repetíveis no lançamento do aplicativo [exclusivamente] no Samsung S7 Edge + Android 7.0) é assim:

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

O problema original parece ter sido corrigido por cada uma das seguintes compilações:
@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

No entanto, consegui estimular outra falha em duas ocasiões para o último deles ( @kudo-ci/jsc-android@241213-fix-clear-cache-dfg ) em um dispositivo diferente e com um backtrace diferente:

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

Embora eu tenha conseguido travar o aplicativo de teste duas vezes, a cada vez com a mesma assinatura, o travamento não é sistematicamente repetido e ocorre durante a navegação entre telas diferentes no aplicativo de teste e não na inicialização. Como o dispositivo relevante está à mão, fui capaz de extrair um rastreamento mais completo do dispositivo que diz o seguinte:

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>

e

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>

Não tenho ideia se isso ajuda, depuração de falhas e interpretação no Android não é algo que eu fiz antes

@Kudo Aqui estão minhas descobertas:

O Samsung S5 é armeabi-v7a . Eu tentei todas as 4 alternativas que você forneceu, e aquela sem jit parece ser a única sem falhas. Desativar dfg reduz bastante a taxa de travamento, mas ainda posso travá-lo.

Também estou testando em um Pixel XL ( arm64-v8a ) e ainda não encontrei nenhuma falha em kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg mas a falha é difícil de reproduzir em dispositivos de última geração, pois a causa raiz parece ser baixa pressão de memória.

Resumindo:
@kudo-ci/jsc-android@241213-no-jit : Sem falhas em ambos os dispositivos
@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg : Isto trava em dispositivos de gama baixa, não pode reproduzir em dispositivos de gama alta
@kudo-ci/jsc-android@241213-fix-clear-cache-dfg : Este trava com mais frequência do que o outro construído em um dispositivo de baixo custo. (ainda melhor do que o estoque RN 59 jsc)
@kudo-ci/jsc-android@241213-no-dfg-jit : Isso travou em dispositivos de gama baixa também, eu não testei em uma gama alta.

Mesmo a construção sem jit é consideravelmente mais rápida do que os JSCs de estoque, portanto, estamos planejando usar @kudo-ci/jsc-android@241213-no-jit e iremos testá-lo mais para garantir que esteja pronto para a produção.

Muito obrigado por toda a ajuda por sinal. Deixe-me saber se eu puder ajudar

@timhatch @tuncaulubilge Obrigado por seus testes e feedback sistemáticos incríveis.
No momento, não tenho ideia de como resolver o problema.
Nem desabilitar DFG nem corrigir __clear_cache ajuda nisso.
Além disso, a falha ocorre no arm32 também (e a causa raiz pode ser diferente do arm64)

Em minha opinião pessoal, gostaria de desabilitar o JIT por padrão, pelo menos para ter certeza de que primeiro temos um JSC sem falhas.
BTW @tuncaulubilge, como você mediu que @kudo-ci/jsc-android@241213-no-jit é mais rápido do que o JSC de estoque?
Só por curiosidade, pois a partir do resultado do benchmark, a versão no-jit age um pouco mais devagar.

@Kudo Você também mediu o tempo de inicialização do aplicativo e o uso de memória? Sempre presumi que essas duas métricas seriam melhores sem o JIT. Como a maioria dos aplicativos tem interface pesada, não tenho certeza se o JIT será muito útil em aplicativos do mundo real, então adoraria ter o JIT desativado se isso melhorar a inicialização e o uso de memória. Também estou curioso para saber se o JSC terá uma pegada de disco menor sem JIT.

@Kudo
Corrigir __clear_cache como você fez nessas compilações de teste está definitivamente melhorando a situação, mas há um efeito colateral da correção ou uma interação mais complexa que ainda não é óbvia. Dito isso, não consegui travar novamente o aplicativo de teste -fix-clear-cache-dfg . Pode ser que, como @tuncaulubilge diz, o comportamento dependa da pressão da memória e / ou outros fatores.

Desativar o JIT completamente parece ser a opção "sem falhas", não notei degradações de desempenho com essa opção, então seria a escolha "segura".

@Kudo para esclarecer, estive comparando o React-Native 0.58.6 (sem qualquer jsc customizado instalado) vs 0.59.8 com @kudo-ci/jsc-android@241213-no-jit .

Não fiz nenhuma medição, mas a melhoria de desempenho é muito perceptível. Eu esperaria que a versão no jit fosse um pouco mais lenta do que a [email protected] como você mencionou, mas isso é ignorável em comparação. Eu sugiro ir com a versão no-jit como a opção padrão também, já que as melhorias de estabilidade superam fortemente a pequena melhoria de desempenho que você obteria do jit.

Estamos usando Expo v32 para construir nosso aplicativo e estamos vendo esse erro em todas as versões e dispositivos Android.

@ tido64 TTI não tem muitas diferenças. O tamanho binário reduz cerca de 1 MB da versão no_dfg. A memória reduz cerca de 48%.
Enviei um PR para desabilitar totalmente o JIT e há resultado de medição.
https://github.com/react-native-community/jsc-android-buildscripts/pull/108

@timhatch Bom saber que consertar __clear_cache ajuda um pouco.
Ainda duvido que a causa raiz seja big.LITTLE, mas ainda não encontrei outro código JSC que causasse problemas.
Ambos Samsung S5 e S7 são big.LITTLE e os dois conjuntos de CPU têm tamanhos de linha de cache diferentes.
Essa talvez seja a razão pela qual não consegui reproduzir o travamento no Samsung Note 5, que os dois processadores com tamanho de linha de cache são 64B.
Não tenho certeza se é possível para o agendador do SO e JSC fazer a transição entre grande <-> PEQUENA CPU no tempo de execução.
Se for verdade, o problema pode ocorrer especialmente naquele momento.

@tuncaulubilge Isso é curioso para mim.
Você pode verificar meu PR , a versão no-jit é mais lenta do que o estoque RN058 JSC.
Isso também foi o que senti durante a medição.
Talvez os benchmarks sejam casos extremos e bem diferentes de um aplicativo RN costumava ser.
BTW, eu vi que o tamanho binário e o tamanho da memória reduzem da versão no-jit.
Esses dois benefícios e sem travamento são mais razoáveis ​​para mim.

Este código salva vidas

@RomanovYurii Quando removemos os filtros ndk de 64 bits "arm64-v8a", "x86_64" do ndk abiFilters no bloco defaultConfig de build.gradle por fornecer suporte apenas de 32 bits. A falha foi embora, mas de acordo com o mandato de suporte de 64 bits do Google, isso precisa ser corrigido com o suporte ndk de 64 bits.

25060

@dishantwalia @Kudo desativado JIT funciona para mim em 64 bits e não vi nenhum problema de desempenho até agora.

Esta essência funcionou para mim https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Queridos,

Publicamos o no-JIT JSC no jsc-android npm e revisei minha essência anterior para usar jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Esperançosamente, para corrigir todos os problemas de travamento.
Se não houver queda significativa de desempenho, iremos propor a versão no-JIT oficialmente como a versão mais recente e enviaremos um PR para incorporá- la no RN mais recente.

Queridos,

Publicamos o no-JIT JSC no jsc-android npm e revisei minha essência anterior para usar jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Esperançosamente, para corrigir todos os problemas de travamento.
Se não houver queda significativa de desempenho, iremos propor a versão no-JIT oficialmente como a versão mais recente e enviaremos um PR para incorporá- la no RN mais recente.

Obrigado @Kudo disable-jit funciona como um encanto para nós !!!

Obrigado @Kudo por todo o trabalho duro! 241213.2.0 parece ter resolvido as falhas para nós. Infelizmente, o impacto no desempenho é bastante significativo. Em dispositivos de baixo custo em algumas de nossas telas mais ocupadas, vimos js fps diminuir em 20-30%.

Eu também posso confirmar que os travamentos desapareceram, mas também estamos vendo um desempenho muito fraco em dispositivos de gama baixa. Devo dizer que é extremamente decepcionante, considerando que estávamos esperando para atualizar para o RN58 / RN59 para o JSC mais moderno.

@kudo no pior cenário, o jit deve ser desativado apenas para a versão de 64 bits, apenas dispositivos com capacidade para 64 bits estão travando

@yenda se essa compilação se tornar a correção, seria bom ter essa opção, sim. Não tenho certeza de como seria difícil. Esperançosamente, isso não significaria enviar duas versões do JSC

@benoitdion @ItsNoHax Você pode listar os dispositivos específicos nos quais observou baixo desempenho? Obrigado!

Testado em um Nexus 5 e Samsung Tab E entre outros.

Para qualquer Googlers que estejam atualizando seu projeto RN para 59.x, certifique-se de que em android/app/build.gradle -> android {defaultConfig {versionName}} não está sendo correspondido com sua versão especificada react-native-code-push.

Lutei cerca de três dias para o mesmo problema e depois descobri que meu projeto React Native atualizado na v59.3 estava sendo atualizado por push de código que tem React Native v54.7

Não deve ser o caso de 90% das pessoas. Mas, para alguns como eu, pode economizar tempo.

Depois disso, obrigado a @Kudo. Corrigidos os problemas de travamento.

Huawei Honor 8X também tem esse problema

Eu também posso confirmar que os travamentos desapareceram, mas também estamos vendo um desempenho muito fraco em dispositivos de gama baixa. Devo dizer que é extremamente decepcionante, considerando que estávamos esperando para atualizar para o RN58 / RN59 para o JSC mais moderno.

O mesmo aqui. O antigo RN no Android era lento e travava, o novo RN é rápido e travava e com essa correção o novo RN é estável e lento. Parece que não podemos ter tudo no Android. 🙈

Queridos,

Lamento que o desempenho tenha sido ruim para a versão no-JIT.
E desculpe, não tenho soluções agora.
É difícil para mim solucionar esse problema que não consegui reproduzir.
Espero que alguém da comunidade possa ajudar a resolver o problema.

JSC for RN é OSS em https://github.com/react-native-community/jsc-android-buildscripts.
Ele oferece suporte para habilitar a compilação de depuração descomentando a linha em https://github.com/react-native-community/jsc-android-buildscripts/blob/master/scripts/start.sh#L10.
Anexando gdb ou lldb para depurar nativamente, talvez haja alguma pista.
A falha pode violar algum RELEASE_ASSERT em https://trac.webkit.org/browser/webkit/releases/WebKitGTK/webkit-2.22.6/Source/JavaScriptCore/jit/JITOperations.cpp#L1067 , mas não tenho certeza de como o problema está indo para o estado.

Obrigado por todo o seu trabalho nisso e jsc-android-buildscripts @Kudo. Tem sido incrível acompanhar o seu progresso! Há algo que nós (a comunidade que está assistindo a este problema) possamos fazer para ajudar? Acredito que @tuncaulubilge teve um caso de reprodução estável em grande parte.

Talvez a equipe interna de reação nativa do Facebook tenha especialistas em jsc?

Acabei de enfrentar esse problema, só acontece no REAL DEVICE, LENOVO A701a48, RUNNING ANDROID 6.
excluindo "arm64-v8a", "x86_64" de

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

resolveu, mas me senti um pouco hack-y.

Espero que haja atualizações da equipe de RN em breve :(

Queridos,

Esta é provavelmente minha última tentativa - usar a versão mais recente do WebKit.
@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg é baseado no WebKitGTK 2.24.2, com JIT de linha de base, mas sem JIT de DFG.
Uma mudança notável é que o WebKit mais recente mudou o formato de bytecode JIT.
O JIT do x86 não é suportado e o suporte JIT da armeabi-v7a é da comunidade (Obrigado Igalia).
Como o travamento ocorre apenas no arm64, vale a pena tentar a nova versão.

As etapas detalhadas para integrar esta versão estão em https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md.
mudança notável é que 241213 -> 245459 da versão JSC anterior e certifique-se de ter 245459.9000.0 no log do adb.
Por favor, ajude a verificar este JSC experimentado.
Espero que tenhamos sorte desta vez. 🤞

@benoitdion obrigado pelo seu incentivo ❤️

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

Pode confirmar que a falha que estava acontecendo com o RN v0.59, ao usar o JSC acima, desapareceu. Testado no Google Nexus 6, outros serão confirmados após o lançamento.

Obrigado!!

@Kudo , posso confirmar que @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg funciona para mim. Nenhuma falha ocorreu no Samsung Galaxy S7 SM-G930FD que estava acontecendo anteriormente com RN v0.59 e foi corrigido com no-jit ou jsc-android v241213.2.0 .

Ainda não tive a chance de integrar esta nova construção, pois tenho alguns outros marcos do projeto atrapalhando, mas planejo fazê-lo assim que eles estiverem fora do caminho.

As compilações no-dfg originais de @Kudo consertaram 99% dos travamentos que eu tinha visto e, embora eu pudesse estimular um único travamento, não consegui repeti-lo.

Eu acredito que @tuncaulubilge foi capaz de reproduzir travamentos com as compilações no-dfg originais, então seria interessante ver o que ele acha dessa nova compilação.

@rimzici @dishantwalia @timhatch Obrigado pela ajuda.

@tuncaulubilge Se você tiver tempo disponível, poderia ajudar a verificar a última versão experimentada?
IIRC, apenas você e @timhatch relataram travamentos de " 241213 -fix-clear-cache-no-dfg" da última vez.
Esperamos poder corrigir as falhas com a versão atualizada.
Obrigado.

@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
tenho esse problema após a integração de @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg no ZTE Blade, Samsung S8, OnePlus 6. Apenas no Motorola Z2 Android 7.1.1 começou 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
tenho esse problema após a integração de @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg no ZTE Blade, Samsung S8, OnePlus 6. Apenas no Motorola Z2 Android 7.1.1 começou a compilar!

Isso parece relacionado a realm , verifique https://github.com/realm/realm-js/issues/2261#issuecomment -468691502
https://github.com/realm/realm-js/issues/2221

@Kudo Mais uma vez, obrigado pelo ótimo trabalho! Infelizmente, mudei para um novo projeto e não tenho mais acesso ao projeto antigo. Vou tentar entrar em contato com meus antigos companheiros de equipe e fazer com que alguém faça uma tentativa.

Estávamos tendo travamentos, especialmente em reactRootView.unmountReactApplication , o que aciona a coleta de lixo, levando a travamentos ocasionais. Você pode reproduzi-lo com um aplicativo de amostra, criando e destruindo 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
tenho esse problema após a integração de @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg no ZTE Blade, Samsung S8, OnePlus 6. Apenas no Motorola Z2 Android 7.1.1 começou a compilar!

Isso parece relacionado a realm verifique realm / realm-js # 2261 (comentário)
realm / realm-js # 2221

Muito obrigado! Só tive que atualizar o reino para 2.28.
@Kudo agradecimentos especiais. Meu aplicativo já funciona corretamente!

@Kudo Eu reconstruí uma versão de um aplicativo afetado anteriormente com a mesma configuração de compilação dos testes anteriores, mas usando @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .
Sem travamentos ou travamentos até agora - vou ver se consigo estressar o aplicativo durante o fim de semana e relatar se encontrar algum problema.

@timhatch Muito obrigado e por favor, durante o fim de semana.
Cruzando os dedos para ouvir boas notícias suas na próxima vez.

Não consigo construir com o patch. Estou recebendo o seguinte erro do FBSDK:

`` ``
Tarefa: 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 : erro: não é possível encontrar o símbolo
@ReactMethod (isBlockingSynchronousMethod = true)
^
símbolo: método isBlockingSynchronousMethod ()
localização: @interface ReactMethod
Nota: Alguns arquivos de entrada usam ou substituem uma API obsoleta.
Nota: Recompile com -Xlint: deprecation para obter detalhes.
Nota: /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java usa operações não verificadas ou não seguras.
Nota: Recompile com -Xlint: desmarcado para obter detalhes.
1 erro

FALHA: a compilação falhou com uma exceção.
`` ``

@wmonecke O problema parece estranho para mim. Não toquei em nenhum código java ou dependências do Gradle no JSC AAR.
Você poderia verificar o problema ou descrever brevemente como aplicar o patch?
Eu acho que você acidentalmente usa dependência RN antiga e
você pode verificar por ./gradlew :app:dependencies | grep 'com.facebook.react:react-native:' (certifique-se de que a versão RN retornada é a que você esperava).

Não consigo construir com o patch. Estou recebendo o seguinte erro do 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 você deve adicionar ambos os repositórios maven (
maven {
// Todo o React Native (JS, fontes Obj-C, binários Android) é instalado a partir do npm
url "$ rootDir /../ node_modules / react-native / android"
}

maven {
// Repo Maven local contendo AARs com biblioteca JSC construída para Android
url "$ rootDir /../ node_modules / @ kudo-ci / jsc-android / dist"
}

@Kudo Sem problemas com @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Nenhum aplicativo trava ou falha.

@Kudo Sem problemas com @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Nenhum aplicativo trava ou falha.

@Kudo Por favor, jsc-android-buildscripts e publique uma versão. Portanto, podemos implementar isso em nossos aplicativos de produção https://github.com/react-native-community/jsc-android-buildscripts.

@timhatch Incrível! Especialmente obrigado pela sua verificação. Empurrará as mudanças JSC para RN em breve.

@dishantwalia Sim, em andamento. Obrigado.

Obrigado @Kudo por todo o seu trabalho nisso. Você (ou outra pessoa que sabe o que está acontecendo) pode me orientar na direção certa para implementar essa correção (sei que é um trabalho em andamento).

Atualmente estou em RN 0.59.9. Com as mudanças implementadas, uma versão atualizada do RN estará disponível algo como 0.59.10 ou devo instalar jsc-android-buildscripts como um pacote de terceiros e implementar para 0,59x de acordo com a documentação?

@Kudo Sem problemas com sua última versão. Ótimo trabalho! 💪

Obrigado @Kudo , eu tenho a mesma pergunta que @jacquesdev está fazendo 0.59.10 ou jsc-android-buildscripts ?

@Kudo @dishantwalia
Obrigado! Eu estava apenas mantendo:
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 infelizmente o problema ainda está aí (Galaxy S7, Android7). Tentei @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .

Eu também tentei a versão no-JIT, o que não ajudou. Eu não consegui fazer com que a versão "JavaScriptCore" fosse impressa no adb logcat usando o grep que você forneceu, nem vi qualquer menção a JavaScriptCore no próprio log, procurando manualmente.

Posso reproduzir a falha com bastante frequência. Nem sempre para no mesmo lugar.

Aqui está o erro (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>

O backtrace não está dizendo nada significativo.

Também mencionarei que não tenho Android7 oficial no meu Galaxy S7 porque era impossível fazer o downgrade do Android8 (não era possível produzir o problema com o Android8), então tive que encontrar rom personalizado que suportasse Android7.

Estou investigando a tentativa de compilar minha própria versão de depuração do jsc-android usando seu último commit em jsc-android-buildscripts, mas vai demorar um pouco.

Acredito que estamos tendo o mesmo 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 versão Android:

Versão | Número | Por cento
- | - | -
Android 7.0 | 66 100,0%

Por dispositivo:

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

Também tenho obtido o travamento do Galaxy S7 após atualizar o RN de 0.58.6 para 0.59.9.

A versão npm atual de jsc-android ainda faz o aplicativo travar, mas usar @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg e a versão JSC 245459.9000.0 consertou o travamento para mim no S7.

@ChrisEelmaa O log "JavaScriptCore.Version" no adb logcat é uma forma de confirmar a escolha da versão correta do JSC.
Porque RN 0.59 tem libjsc.so embutido e pickFirst '** / libjsc.so' não é confiável em minha opinião.

Uma maneira alternativa de confirmar a versão JSC seria seguir as etapas:

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

A saída deve ser algo como:

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

@Kudo obrigado por sua correção, parece evitar que o inferno aconteça.

Meus 2 centavos aí: Eu não tenho uma pasta jni mas sim uma lib one, então use este comando para verificar a versão após descompactar:

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

Obrigado @Kudo

Anteriormente eu tinha o react-native 0.58.3, vejo pessoas mencionando 0.59 o tempo todo, então decidi também atualizar. A combinação de ter 0.59.0 e @ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg pareceu funcionar para mim.

Não consigo mais produzir o acidente.

Alguém sabe se uma correção para este problema estará na próxima versão RN?

Alguém sabe se uma correção para este problema estará na próxima versão RN?

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

@kristerkari
Só para confirmar os passos que você seguiu.

Você seguiu as instruções aqui, https://github.com/react-native-community/jsc-android-buildscripts#for -react-native-version-059

Mas você trocou em vez de adicionar "jsc-android": "241213.x.x", , você adicionou @kudo-ci/jsc-android": "^245459.9000.0 ao seu package.json? Você fez alguma outra alteração?

Por exemplo, vejo que em build.grade, você deve adicionar implementation "org.webkit:android-jsc:r241213" , essa linha também deve ser alterada e, se sim, qual deve ser?

Continuo recebendo o erro de compilação Could not find org.webkit:android-jsc:r241213. ou Could not find org.webkit:android-jsc:r245459.9000.0. Portanto, estou supondo que meu problema está usando a referência errada, mas não consigo dizer qual deveria ser.

@jacquesdev, siga as etapas neste guia: https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md

Queridos,

Apenas para atualizar isso com a ajuda de @kmagiera , meu patch foi publicado como ' [email protected] '.
Enviei https://github.com/facebook/react-native/pull/25426 para ter o JSC atualizado no RN.
E @kelset também tem em RN 0.60 RC.
Esperamos poder finalmente corrigir e fechar esse problema.
Grite para as pessoas aqui especialmente pela ajuda para verificar minhas versões experimentadas e para trás.
Somos a chamada comunidade RN!

Obrigado @Kudo! Você tem alguma ideia se isso tem alguma chance de gerar uma versão 0.59.x ou é provável que seja apenas em 0.60?

Seria incrível se pudéssemos obtê-lo em 0.59.x
0.60 tem muitas mudanças importantes com AndroidX e bibliotecas externas.

1 para nós, colocá-lo em 0.59.x resolveria muitos problemas para nossos
aplicativos.

Realmente não quero ir para 0,60 por causa do suporte do Android X em
bibliotecas até agora.

O pickFirst para JSC não funcionou para nós, deve ser uma de nossas bibliotecas nativas
causando um problema, mas parece sempre escolher a versão interna da rn.
(O projeto limpo funcionou, então deve ser um de nossos departamentos causando isso)

Kirk

Sábado, 29 de junho de 2019, 19:35 Anurag Dadheech, [email protected]
escrevi:

Seria incrível se pudéssemos obtê-lo em 0.59.x
0.60 tem muitas mudanças importantes com AndroidX e bibliotecas externas.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ25TBIFBOI3QWMSPXLP46TN3A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY355CI#issuecomment-506977929 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AABPHZ2D5WUEM4S3242ZTYTP46TN3ANCNFSM4HC77RAQ
.

Olá, posso saber onde adicionar este "@ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg "?

Olá @Kudo, obrigado pelo seu excelente trabalho!

No antigo WebKit sem DFG JIT, travamentos ainda ocorrem, mas o WebKit 2.24.2 mais recente sem DFG JIT parece consertá-lo. Estou me perguntando se vale a pena experimentar este novo WebKit com DFG JIT habilitado para permitir o melhor desempenho possível se funcionar.

Eu concordo com alguns comentários antes que seria melhor ter um 0.59.10 com esta correção porque será mais difícil atualizar para 0.60 @Kudo @kelset @grabbou @turnrye

Tenho o mesmo problema aqui,

Não podemos atualizar para 0.60 porque o react-native-maps ainda não suporta AndroidX, não podemos enviar nossas atualizações para 0.59.X porque S7 e S7 plus travam.

Este é realmente um problema para as empresas que dependem da reação nativa

Existe alguma solução alternativa para isso?

Concordo com @adnkh , não podemos atualizar para o AndroidX agora, mas precisamos resolver as falhas de 0,59.

Você não precisa atualizar para 0,60 para consumir a correção. Você deve ser capaz de seguir as instruções em https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. A versão que você deseja instalar é 245459.0.0 ou superior.

Olá @benoitdion ,

Sim, é possível consumir mesmo que não esteja na biblioteca principal, na verdade, eu segui essas instruções https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 . e funcionou

Mas não acho que seja uma solução permanente e legal por causa das muitas coisas que você precisa adicionar ao seu projeto Android, acho que um hotfix no RN principal seria mais conveniente do ponto de vista do desenvolvedor e resolve muitos problemas de travamento em aplicativos Android

Você não precisa atualizar para 0,60 para consumir a correção. Você deve ser capaz de seguir as instruções em https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. A versão que você deseja instalar é 245459.0.0 ou superior.

@benoitdion sim, mas é uma solução alternativa, uma correção oficial publicada como 0.59.10 seria melhor.

Obrigado @Kudo
Use @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg reduziu a maioria das falhas
Mas ainda existem algumas falhas na produção

xiaomi MIX 3 XiaoMi / MIUI Android 9, nível 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, nível 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, nível 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.

Ouvimos todos vocês e, por causa dos problemas que muitos de vocês estão tendo, fizemos um último lançamento de patch 0.59.10 para fornecer a vocês a nova versão do JSC.

Muito obrigado a port para 0,59.

Não faremos outros lançamentos de 0,59 em um futuro previsível, pois é um trabalho desafiador e ainda mais difícil porque também estamos trabalhando no 0,60 (que terá o novo JSC também!).

Vou encerrar isso porque o problema principal foi resolvido, mas sugiro abrir um novo para outras falhas que podem ocorrer após 0.59.10.

Excelente notícia !!

Obrigado a todos, especialmente @kudo !!

Na terça, 2 de julho de 2019, 12h29 Lorenzo Sciandra, [email protected]
escrevi:

👋 todos.

Ouvimos todos vocês, e por causa dos problemas que muitos de vocês estão tendo,
fez um último lançamento de patch 0.59.10 para fornecer a você a nova versão do
o JSC.

Muito obrigado a https://github.com/Kudo por seu trabalho em
retroceder para 0,59.

Não faremos novos lançamentos 0,59, pois é um trabalho desafiador e até
mais difícil porque também estamos trabalhando em 0.60 (que terá o novo JSC
também!).

Vou encerrar isso porque o problema principal foi resolvido, mas
sugira abrir um novo para outras falhas que você possa estar enfrentando
após 0.59.10.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZZG2Z764HFNPJB7UVTP5M325A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZA6LHI#issuecomment-507635101 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AABPHZ5PYT4F7ZZGQXZKKKLP5M325ANCNFSM4HC77RAQ
.

Muito obrigado pela correção! Depois de atualizar o react-native para a versão 0.59.10 , ainda preciso implementar as etapas mencionadas aqui ?

Kevin,

Após a atualização para RN 0.59.10, você não precisa seguir nenhum dos princípios
instruções por mais tempo.

K

Na quarta-feira, 3 de julho de 2019, 15:42 Kevin Etore, [email protected] escreveu:

Muito obrigado pela correção! Após atualizar o react-native para a versão 0.59.10,
ainda preciso implementar as etapas mencionadas aqui
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 ?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ6H66HMI6CFMXMR4Y3P5S3DVA5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZEVDYQ#issuecomment-508121570 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AABPHZ6UMO5NS4F4OZ7RWPTP5S3DVANCNFSM4HC77RAQ
.

Meu aplicativo ainda falha no Meizu M5s M612H Android OS 6 com RN-0.59.10. Eu criei um novo problema como @kelset sugeriu.

Ainda travando no Caterpillar S41 (Android 8.0). A correção resolveu o problema em todos os outros dispositivos. Também criou um novo problema . Diga-me se esta não é a maneira certa de fazer.

Oi pessoal
Meu aplicativo também falha em algum dispositivo Android ao compilar em 64 bits

Você está usando o pacote react -native-elements versão 1.1.0 ??
Porque o componente Header travou meu aplicativo e também o componente Avatar quando coloco o ícone de prop ou título

Outra pessoa pode verificar se a mesma coisa acontece com eles?

algum proprietário de s7 teve a chance de testar esse problema com Hermes?

se eu usar o aplicativo abaixo e for aceito pela google play store
ndk {abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"}
se eu usar o aplicativo abaixo, está funcionando, mas não é aceito pela google play store
ndk {abiFilters "armeabi-v7a", "x86"}

por favor, qualquer um me ajude a resolver

Ainda trava no Moto G7 e no Pixel 2 (ambos Android 9.0) com o APK de 64 bits. Ele funciona bem com o APK de 32 bits.

@ afras21 - isso ocorre porque o bug existe na versão de 64 bits, que a Google Play Store está tornando obrigatório.

@jacquesdev Obrigado jacq, agora eles removeram o obrigatório e agora está funcionando

@ afras21, você quer dizer que o google retirou a restrição de 64 bits da playstore?

Eu tenho o mesmo problema. Se eu atualizar meu projeto de 0.59.9 para 0.60.4, devo corrigir o problema?

Eu tenho o mesmo problema. Atualmente, estou usando 0.59.9. Se eu atualizar para 0.60.x, o problema será resolvido?

Tente primeiro se o 0.59.10 resolveu os problemas para você.
Se não, talvez valha a pena atualizar o RN 0.60.4 e ligar o Hermes .

Repetindo o que Kudo disse, apenas dando contexto e resumindo o conteúdo anterior desta edição (já que provavelmente é difícil classificar tantos comentários neste momento):

Se você tiver 0.59.9 ou inferior, este é um problema verificado com o JSC antigo. É o assunto de centenas de comentários acima (e em outras edições). O problema não é exclusivo de 64 bits, mas ocorre com mais freqüência com 64 bits.

0.60+ tem várias alterações importantes, especialmente no Android.

Se você não quiser passar por isso, tente 0.59.10, pois tem a correção (conforme descrito acima) integrada diretamente na versão / compilação - e parece corrigir o problema na maioria dos casos.

Ainda há casos em que há problemas para certos telefones (que eu também encontrei), consulte # 25494 - se você tiver isso, sugiro postar seus rastreamentos de pilha para esse problema aberto. No entanto, se você está dizendo que tem 0.59.9, você pode _provavelmente_ corrigir seu problema indo para 0.59.10.

@MalcolmScruggs @ntorion @ harryt2
Você resolveu isso? Como resolver？ Obrigado

0.59.10 não resolveu para mim. Vou tentar fazer a atualização 0.60.x

@MalcolmScruggs @ntorion @ harryt2
Você resolveu isso? Como resolver？ Obrigado

0.59.10 também não resolveu para mim. Não consigo atualizar para 0.60.x porque algumas das minhas dependências não funcionam. Consegui compilar no Hermes, mas vi um grande aumento nos ANRs (graças a Deus pelo lançamento em etapas). Ainda estou na Play Store com a versão RN 0.57.8, mas não consigo mais atualizar meu aplicativo devido ao requisito de 64 bits. Muito frustrado e tentando decidir se apenas reconstruir o aplicativo inteiro com outro framework.

@ harryt2 @rogerkerse Obrigado.
Minha situação é ainda pior. A versão lançada tem bugs, então tenho que atualizar o aplicativo 64. Não consigo resolver esse problema no momento. Também estou tentando flutter, mas não uma substituição completa tão rápida.

Na verdade, tive o trabalho de aumentar o React-Native para 0.60.5 e ativar o Hermes + 64-bit (o que foi uma dor, pois atualizar o react-native sempre é) e ainda estou tendo esses problemas em vários telefones Android (incluindo HUAWEI MYA-L41).

Eu tentei quase tudo que encontrei em outros tópicos sem muita sorte, então posso dizer que bater reagente-nativo e usar Hermes não corrige todos esses problemas.

O Reac nativo atualizado + Hermes e 64 bits é incrível em outros dispositivos Android em que o executei e nosso aplicativo nunca foi tão suave.

No entanto, sempre que eu testo no dispositivo específico que mencionei (Huawei), ele trava instantaneamente ou depois que o aplicativo é aberto por 1-2 segundos sem uma mensagem de falha específica, não tenho nenhum outro dispositivo além desse e um Huawei mais recente ( que funciona perfeitamente), por isso não posso dar mais informações sobre outros telefones.

Se alguém fez algum progresso com este problema ou tem alguma idéia para registrar mais especificamente meus problemas, conselhos são sempre bem-vindos e estou disposto a compartilhar qualquer informação sobre este assunto.
Obrigado às pessoas neste tópico por oferecerem soluções, mas sem sorte até agora. 🙂

@YoranRoels Você já tentou executar um aplicativo limpo criado por init

@armenbadalyan Obrigado pela resposta rápida.

Acabei de configurar um novo projeto e tentei executá-lo no dispositivo e tudo parece estar bem, então no final parece algo com a minha configuração. Existe uma maneira eficiente de depurar isso, já que meu logcat não expele nada útil além de com.<our_app_id> foi eliminado?

React Native 59.10 também não resolve para nós. O aplicativo ainda trava na primeira inicialização.

@GreanBeetle Veja https://github.com/facebook/react-native/issues/25494. 0.59.10, infelizmente, é conhecido neste ponto por não corrigir este problema em todos os casos.

O caminho mais atualizado é usar (como neste tópico), 0.60+ e Hermes.

@YoranRoels Obtenha a lápide do dispositivo. Veja: https://github.com/facebook/react-native/issues/24261#issuecomment -490239902

@GreanBeetle Você pode usar o motor V8 em 0.59.10 para se livrar deste problema
https://github.com/Kudo/react-native-v8

Obrigado @ j-wang. @manuhook vai tentar sua solução.

@GreanBeetle Você pode usar o motor V8 em 0.59.10 para se livrar deste problema
https://github.com/Kudo/react-native-v8

Pode confirmar que isso resolveu o problema para nós. As compilações de 64 bits com react-native-v8 em 0.59.10 não estão mais travando e podemos finalmente enviar atualizações novamente no Google Play. Obrigado!

Eu tentei o registro de tombstone que @ j-wang mencionou, mas nunca usei isso e era um arquivo imenso que era difícil de ler, depois de procurar por um tempo eu realmente não parecia encontrar uma causa raiz legível.

Depois de seguir o conselho de @armenbadalyan , comecei a me perguntar se não era algo bobo no início do nosso aplicativo e, com certeza, ao remover a IU do primeiro componente, percebi que o aplicativo estava funcionando novamente, estável. Então, depois de mais pesquisar, percebi que um componente específico tinha problemas onde uma imagem era renderizada.

Nesse componente, há uma chance de passarmos null como a variável source em um react-native Image . Levei um tempo para procurar por isso e não houve erros claros, mas finalmente consertou tudo para mim e está sendo executado em todos os nossos dispositivos de teste. Ainda não tenho ideia de por que não falhou em nosso outro dispositivo de teste ...

Pode ajudar outras pessoas a simplificar o primeiro componente de seu aplicativo para garantir que ele não esteja travando naquele código.

TL; DR : Isso provavelmente está completamente fora do assunto agora, mas a quem interessa: NÃO USE null COMO A source VARIÁVEL DE Image , não t funcionar em todos os dispositivos. 😅

@ harryt2 sim, eu também. Tive um grande aumento nos ANRs após atualizar para RN 0,60. +

Uma pequena ajuda para aqueles que ainda estão tentando resolver a falha de inicialização:

1. execute adb logcat em um console
2. espere que o spam do console pare
3. abra o aplicativo com falha em seu dispositivo
4. pare o adb logcat com Ctrl + c
5. role para cima e encontre a falha

Isso não resolve o problema, mas permite que você descubra algo mais. Eu tenho 2 aplicativos, um está funcionando bem com o de 64 bits, ainda tendo problemas com o outro, mesmo que tenham a mesma configuração. Meu dispositivo com falha é um One Plus 5t (64 bits)

Acabei de ver isso em um novo lançamento de nosso aplicativo, construído com RN 59.10, especificamente em um Samsung Galaxy Note9 no Android 9. Alguém mais está vendo um problema semelhante?

@msspshaw Como mencionado acima e na outra edição, sim. O novo JSC congela / falha aleatoriamente em certos dispositivos Android porque obtém lixo coletado de forma não determinística - então, todo o aplicativo falha.

A solução é atualizar para 0.60+ e usar Hermes, ou trocar JSC para v8.

Eu tentei o registro de tombstone que @ j-wang mencionou, mas nunca usei isso e era um arquivo imenso que era difícil de ler, depois de procurar por um tempo eu realmente não parecia encontrar uma causa raiz legível.

Depois de seguir o conselho de @armenbadalyan , comecei a me perguntar se não era algo bobo no início do nosso aplicativo e, com certeza, ao remover a IU do primeiro componente, percebi que o aplicativo estava funcionando novamente, estável. Então, depois de mais pesquisar, percebi que um componente específico tinha problemas onde uma imagem era renderizada.

Nesse componente, há uma chance de passarmos null como a variável source em um react-native Image . Levei um tempo para procurar por isso e não houve erros claros, mas finalmente consertou tudo para mim e está sendo executado em todos os nossos dispositivos de teste. Ainda não tenho ideia de por que não falhou em nosso outro dispositivo de teste ...

Pode ajudar outras pessoas a simplificar o primeiro componente de seu aplicativo para garantir que ele não esteja travando naquele código.

TL; DR : Isso provavelmente está completamente fora do assunto agora, mas a quem interessa: NÃO USE null COMO A source VARIÁVEL DE Image , não t funcionar em todos os dispositivos. 😅

+1 funciona para mim. Eu tive os mesmos problemas. Obrigado!

Veja também acontecendo em um Samsung Galaxy S7 IO-IL 086 com Android 7.0 RN 0.59.10

@BracketMan Você está usando V8 em vez de JSC?

@EmilScherdin ahhh não, não estou. Vou tentar e relatar os agradecimentos.

@EmilScherdin Posso confirmar que rodar no V8 no RN 0.59.10 está funcionando para mim, chega de travamentos.

Obrigado!

Experimentamos o mesmo problema no RN 0.59.10 com v8. Vejo que o JIT não está desabilitado para arm64-v8a e em dispositivos com essa arquitetura temos travamentos.

@mmamoyco Você tem o rastreamento de pilha da falha do V8?

@Kudo Sim, tenho o log de travamento. Mudamos de jsc para v8 porque estávamos enfrentando muitos travamentos. Mas o mesmo está acontecendo com o v8. abaixo está o log

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

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

Tivemos exatamente esse problema no 0.59.1 e fomos capazes de corrigi-lo fazendo o seguinte:

⛄️ Estas instruções não são iguais às do README jsc-android . Modificamos os números de versão e alguns significantes. A versão canary de jsc não corrige o problema. É a versão posterior a jsc-android @ canary que é necessária, consulte: Este patch para a correção original que foi incorporada ao repositório react -nativo. Obrigado a @ ravali121 por ajudar a resolver isso.

1. Adicione jsc-android à seção "dependências" em seu package.json :

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

em seguida, execute npm install ou yarn (dependendo de qual cliente npm você usa) para que a nova dependência seja instalada em node_modules

1. Modifique o arquivo android/build.gradle para adicionar o novo repositório maven local empacotado no pacote jsc-android ao caminho de pesquisa:

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. Atualize o arquivo build.gradle do seu aplicativo localizado em android/app/build.gradle para adicionar a dependência JSC. Certifique-se de que a dependência é anterior à dependência 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. Atualize o arquivo build.gradle do seu aplicativo localizado em android/app/build.gradle para usar a primeira biblioteca JSC correspondente.

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

alguém poderia ajudar a responder a essa pergunta?
https://github.com/react-native-community/jsc-android-buildscripts/issues/127

NÃO USE null COMO A source VARIÁVEL DE Image , ele não funciona em todos os dispositivos. 😅

Eu odeio apenas citar você, mas quase perdi sua solução no barulho deste tópico. Muito obrigado @YoranRoels !! Isso salvou o dia!

Encontrei um site de teste de máquina real online , lá eu escolhi o GALAXY S7 Edge e o sistema operacional Android 7.0, infelizmente não aconteceu travamento e tento usar o método @YoranRoels definido source variável de Image para {null} e {{ uri: null }} mas ainda assim não travou, Horrível, nem sei como aconteceu, Alguém pode me ajudar.

Tivemos exatamente esse problema no 0.59.1 e fomos capazes de corrigi-lo fazendo o seguinte:

⛄️ Estas instruções não são iguais às do README jsc-android . Modificamos os números de versão e alguns significantes. A versão canary de jsc não corrige o problema. É a versão posterior a jsc-android @ canary que é necessária, consulte: Este patch para a correção original que foi incorporada ao repositório react -nativo. Obrigado a @ ravali121 por ajudar a resolver isso.

1. Adicione jsc-android à seção "dependências" em seu package.json :

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

em seguida, execute npm install ou yarn (dependendo de qual cliente npm você usa) para que a nova dependência seja instalada em node_modules

1. Modifique o arquivo android/build.gradle para adicionar o novo repositório maven local empacotado no pacote jsc-android ao caminho de pesquisa:

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. Atualize o arquivo build.gradle do seu aplicativo localizado em android/app/build.gradle para adicionar a dependência JSC. Certifique-se de que a dependência é anterior à dependência 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. Atualize o arquivo build.gradle do seu aplicativo localizado em android/app/build.gradle para usar a primeira biblioteca JSC correspondente.

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

Você é um salva-vidas! ❤️ Há três dias que estou procurando sua resposta para colar esse código e mudar a versão jsc-android exatamente para a que você mencionou. E agora está funcionando! Ocorreu um erro quando atualizei a versão RN de 0,59 para 0,60. O aplicativo estava quebrado apenas para o Android, iOS estava bem. O mais estranho é que o aplicativo foi compilado com sucesso, então tudo parecia ótimo, mas quando foi iniciado, travou imediatamente.