Vielen Dank, dass Sie Ihr Problem eingereicht haben. Können Sie sich Ihre Beschreibung noch einmal ansehen und sicherstellen, dass die Problemvorlage vollständig ausgefüllt wurde?

👉 Klicken Sie hier, wenn Sie sich die Fehlerbericht-Problemvorlage

Vielen Dank, dass Sie Ihr Problem eingereicht haben. Können Sie sich Ihre Beschreibung noch einmal ansehen und sicherstellen, dass die Problemvorlage vollständig ausgefüllt wurde?

👉 Klicken Sie hier, wenn Sie sich die Fehlerbericht-Problemvorlage

Aktualisiert

Logcat-Fehler Screenshot als Referenz

Veröffentlichung eines 64-Bit-Split-Builds Ich bekomme diesen Absturz auch beim Start auf Galaxy S7 und Galaxy S7 Edge mit Android 7.0
Android Vitals zeigen:
Signal 11 (SIGSEGV), Code 1 (SEGV_MAPERR) WTFCrash
Rückverfolgung:
# 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

auf Crashlytics für die Geräte, die ich bekomme:
Tödliche Ausnahme: com.facebook.react.common.c
Invariante Verletzung: Wiederaufnahme der noch nicht umgesetzten Arbeit.

Die Problemumgehung, nur 32-Bit-Build bereitzustellen, löst dies vorerst

Ich sehe genau die gleichen Fehler wie @nadavmos auf dem Galaxy S7 mit Android 7.0. Die App stürzt beim Start ab

Ich sehe genau die gleichen Fehler wie @nadavmos auf dem Galaxy S7 mit Android 7.0. Die App stürzt beim Start ab

@nsantacruz benutzt du auch

@ Nadavmos , ich verwende nicht react-navigation . Dies ist möglicherweise das gleiche Problem wie # 24260, da dieses Problem auch 0,59 mit Samsung S7 unter Android 7.0 betrifft

@nadavmos Der Absturz hängt nicht mit react-navigation . Tatsächlich stürzt die App in einem neuen RN-Projekt ab, das über reaktionsnatives Init erstellt wurde.

@hramos @mkonicek Ab sofort können wir den Schluss ziehen, dass dies ein Problem mit der neuesten Version von RN 0.59 zu sein scheint, das sich auf Android-Builds auswirkt, die auf Samsung S7 , S7 Edge nachdem wir Unterstützung für arm64-v8a bereitgestellt haben x86_64 : Wenn Sie sie aus build.gradle entfernen, stürzt die App nicht ab. Dies kann sich möglicherweise auf Apps auswirken, die nach 1 August 2019 gemäß der 64-Bit-Supportrichtlinie von Google Play live geschaltet werden. Wir möchten, dass ihr bitte darauf aufmerksam macht.

Auch am 0.58.5 passiert. Galaxy S7. Android 6.0. Das Einstellen auf 32-Bit-Build funktioniert ebenfalls nicht.

Wir beobachten die gleichen Abstürze bei 64-Bit-Builds von RN 0.59.4 auf einem Galaxy S7 mit Android 7.0. Leider haben wir keinen Zugriff auf dieses Gerätemodell. Es funktioniert gut bei uns allen.

Das gleiche Problem mit dem Huawai P9-Gerät in der folgenden Umgebung:

  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

Dies ist die Crashlytics-Stapelverfolgung, die wir erhalten:

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

Das gleiche Problem mit Samsung Galaxy S7 auf 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)

~ Wenn Sie dies zu Ihrem android/app/build.gradle ~ hinzufügen, kann dies behoben werden ~ (nicht): ~

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

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

Vielen Dank, dass Sie versucht haben zu helfen, aber die Lösung hat uns nicht geholfen.

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

Das Hinzufügen zu Ihrem Android / App / Build.gradle kann das Problem beheben:

Verpackungsoptionen {
pickFirst ' /libjsc.so'pickFirst ' /libc++_shared.so'
}}
Siehe React-Native-Community / Jsc-Android-Buildscripts # 95 https://github.com/react-native-community/jsc-android-buildscripts/pull/95
Testen Sie dies jetzt.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/facebook/react-native/issues/24261#issuecomment-483728028 an oder schalten Sie den Thread https://github.com/notifications/unsubscribe-auth/ stumm.

Das Hinzufügen zu Ihrem android/app/build.gradle kann das Problem beheben:

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

Siehe React-Native-Community / JSC-Android-Buildscripts # 95

Ich teste das jetzt.

@ AndrewJack hat es bei dir funktioniert?

Das Hinzufügen zu Ihrem android/app/build.gradle kann das Problem beheben:

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

Siehe React-Native-Community / JSC-Android-Buildscripts # 95

Ich teste das jetzt.

Leider hatten wir die schon da drin.

Wir haben unsere 64-Bit-Builds aus dem Play Store gezogen. Dies hängt möglicherweise überhaupt nicht mit dem Absturz im 64-Bit-Build zusammen, aber Galaxy S7-Geräte, auf denen der armeabi-v7a-Build ausgeführt wird, stürzen jetzt wie unten beschrieben häufig ab. Sofort nach dem Start.

Ich frage mich wirklich, was an der S7 im Vergleich zu anderen Geräten so anders ist.

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 Es hat nicht funktioniert, ich dachte, das Korrigieren der Konfiguration von jsc-android-Buildscripts könnte funktionieren.

Ich erhalte die gleiche Ausnahme und sie kann nicht von einem nicht erfassten Ausnahmebehandler abgefangen werden. In meiner Android-App habe ich diesen Code ausprobiert:

Thread.setDefaultUncaughtExceptionHandler(...);

mit dem Handler, der nur den Ausnahmennamen in die Konsole schreibt und dann die Kontrolle an den Standardhandler zurückgibt, aber dieser Code wurde vor dem Absturz der App nicht ausgeführt.

Ich habe versucht zu untersuchen, warum Crashlytics diese Ausnahmen nicht protokolliert. Vielleicht ist das der Grund ... Ich erinnere mich, dass ich ein- oder zweimal native Abstürze in meiner Fabric-Konsole gesehen habe, sodass Crashlytics native Abstürze protokollieren kann, aber in diesem Fall irgendwie nicht.

@SpertsyanKM Der Absturz tritt auf ndk-Ebene auf. Der Absturz wird in der Firebase-Konsole nur angezeigt, wenn Sie die Crashlytics NDK-Bibliothek hinzufügen. https://docs.fabric.io/android/crashlytics/ndk.html

Wie Sie festgestellt haben, werden mit Thread.setDefaultUncaughtExceptionHandler nur Java-Ausnahmen abgefangen.

Ich habe heute ein Upgrade auf RN 0.59.5 durchgeführt und der Absturz tritt immer noch auf. Dieses Problem ist noch nicht behoben.

Hallo allerseits, ich habe das gleiche Problem in 0.59.5, entferne android: screenOrientation = "Porträt" in AndroidManifest.xml. Für mich geht das.

@Jeijie Ich hatte das schon nicht

Gleiches Problem bei REDMI NOTE 4X Android 7.0 und 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]

Gleiches Problem auf Galaxy S7 Edge / Android 7.0 und mit drei verschiedenen Versionen von React-Native: 0.58.4, 0.58.5 und 0.59.5.
Der Absturz wurde auf anderen Android-Geräten nicht erkannt.

Die einzige Lösung, um dieses Problem derzeit zu vermeiden, besteht darin, die App nur auf 32 Bit zu erstellen. Das Problem muss jedoch für den ersten August behoben werden, da der Play Store nicht mehr nur 32-Bit-Apps akzeptiert.

Das Gleiche erleben, beschränkt auf Galaxy S7 mit Android <= 7.0 (nicht 8.0). Passiert, seit wir die 64-Bit-Unterstützung aktiviert haben.

Ab unserer Gradle-Standardkonfiguration unterstützen wir nicht einmal 64-Bit und die Abstürze treten trotzdem auf.
`` `
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 
}```

Ich habe festgestellt, dass das Problem auch bei einigen Mediatek-Geräten auftritt
Alcatel A5 (ELSA6)
Alcatel 1x / TCL L9 (U5A_PLUS_4G)
Einige andere Geräte mit MediaTek SoCs mit x64-Unterstützung

Hallo. Wir haben festgestellt, dass:

1. ~ Der Fix zum Entfernen der 64-Bit-Unterstützung funktioniert ~ Dies hat das Problem nur für einige unserer Benutzer behoben
2. ~ Wir haben Benutzer dieses Problem selbst beheben lassen, indem sie ihr Telefon neu gestartet haben (kein Wechsel zur 32-Bit-App erforderlich). ~ Sie hatten nicht das gleiche Problem.

Ich kann bestätigen, dass durch das Entfernen der 64-Bit-Unterstützung die Absturzberichte um ~ 90% reduziert wurden
Es passiert immer noch mit einigen Geräten. Aber das aktuelle "Update" ist das Beste, was ich derzeit tun kann

Ich bekomme auch Abstürze auf OnePlus 3, aber das Entfernen der 64-Bit-Unterstützung hilft nicht. Ich bekomme Abstürze mit einem sauberen reaktionsnativen Init-Projekt (auch auf Emulatoren beim Öffnen der APK der App).

gleiches Problem s7 edge android 7.0 stürzt in der Produktion mit Bundle Split ab, andere scheinen in Ordnung zu sein
Signal 11 (SIGSEGV), Code 1 (SEGV_MAPERR)
Rückverfolgung:
# 00 pc 000000000009e144
# 01 pc 00000000000a4a70

Dieses Problem wurde bereits im Webkit-Repo identifiziert. Ich habe dort einen Kommentar abgegeben, als ich dieses Problem vor Monaten entdeckte: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/327#issuecomment -436781890

Es wäre großartig, die Bemühungen zu koordinieren.

Hinweis: Bei Youi verwenden wir RN nicht standardmäßig. Wir erstellen unsere eigene 64-Bit-JSC, daher haben wir dieses Problem viel früher als vor 0,58.

Die häufigsten Faktoren scheinen Android 6.0 oder 7.0 (Level 23 & 24) und ARM 64-Geräte zu sein.
Das häufigste Gerät mit dieser Kombination ist die S7. Ein Upgrade einer S7 auf Android 8 behebt das Problem.

Ich habe den Absturz in einem Android ARM 64-Bit-Emulator reproduziert, aber die Bilder des Android ARM-Emulators sind zu instabil und fehlerhaft, um damit zu arbeiten. Ich muss auch eine S7 debuggen, die ich auf Android 7 herunterstufen möchte, obwohl Samsung dies nicht einfach gemacht hat.

@kmagiera & @kudo Sie haben kürzlich eine neue Version von JSC veröffentlicht. Erwarten Sie, dass diese Version dieses Problem behebt? Würde das Ausrichten von NDK-Versionen helfen? https://github.com/react-native-community/jsc-android-buildscripts/pull/95

@AndrewJack Die neue Version nur für WebKit-Sicherheitspatches und zum Entfernen von libc ++ _ shared.so für https://github.com/facebook/react-native/pull/24672. Ich denke nicht, dass dies die Absturzprobleme beheben wird.

AFAIK, es gibt verschiedene JSC-Absturztypen.
Einige stammen von operationLinkDirectCall, wie dieses Problem gemeldet hat, andere von NPE als https://github.com/react-native-community/jsc-android-buildscripts/issues/84.
Die meisten von ihnen sind mit JIT verwandt.
Der JIT-Absturzpfad ist im eigenen Haus schwer zu reproduzieren und auch schwer zu beheben.
Ich habe einige mögliche Korrekturen, bin mir aber nicht ganz sicher, ob diese das Absturzproblem wirklich lösen werden.

• Eine der Korrekturen ist das Deaktivieren von DFG_JIT .

• Es gibt auch einen Fix von der Upstream-bezogenen OperationLinkDirectCall

• Neuere JSC (WebKitGTK 2.24) enthält viele JIT-Änderungen. Es lohnt sich zu versuchen, wenn ein Upgrade hilft.

IMO, wenn eine interne Reproduktion nicht möglich ist, besteht eine Alternative darin, einen experimentierten Build zu liefern.

Mein Plan ist es, das Upgrade von JSC zu vereinfachen, einfach yarn add jsc-android@experiment . Dies sollte bei RN 0,60 geschehen.
Mit diesem Mechanismus könnten wir zumindest einen Schritt voraus sein, um Absturzprobleme zu beheben.

Auf der anderen Seite wäre es hilfreich, wenn es zuverlässigen Reproduktionscode und Umgebung gibt.
Zum Beispiel gibt es ein Repo von React-Native-Navigation. Es hilft viel.
https://github.com/react-native-community/jsc-android-buildscripts/issues/84#issue -407898908

Der Absturz passiert auch auf Pixel 2 mit Android 9, wenn das hilft.
Gibt es eine Möglichkeit, Absturzprotokolle abzurufen, wenn APK ausgeführt wird? Ich werde gerne helfen, um weitere Informationen zu diesen Abstürzen zu erhalten, aber ich weiß nicht viel über die Android-Entwicklung.

@quietbits , die meisten Protokolle, die sich auf diese Probleme beziehen, sind nicht besonders hilfreich, aber um es herauszuholen:

Suchen Sie nach, wann der Absturz mit adb logcat auftritt - es sieht ungefähr so ​​aus (nicht genau, da ich dies gerade aus dem oberen Bereich des Protokolls extrahiert habe, aber es zeigt einen Auszug, weshalb ich darauf zeige aus):

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

Normalerweise wird auch gesagt, dass das Protokoll auf einen "Grabstein" geschrieben ist.

Verwenden Sie adb bugreport ./MySuperSpecialBugReport um den Grabstein zu entfernen, wobei der letzte Teil offensichtlich der Pfad ist, in dem Sie ihn haben möchten.

Es wird als Reißverschluss entfernt, und Sie können es entpacken, (auf den meisten Geräten) zu ./MySuperSpecialBugReport/FS/data/tombstones navigieren und dann den Grabstein mit Ihrem Texteditor öffnen.

Auch hier sind sie angesichts der Art dieser Abstürze nicht besonders informativ. Zumindest bei uns haben sie normalerweise mqt_js und eine niedrige Zeigeradresse. Sie treten auch immer noch (wenn auch immer weniger seltsam / unvorhersehbar) mit nur 32-Bit-Apks auf.

===

@ Kudo - ich freue mich auf jeden Fall darauf, verschiedene JSCs einfacher ausprobieren zu können und zu sehen, was sie bewirken. Dies war bisher ein echtes Problem beim Upgrade auf 0,59 mit nicht deterministischen und unvorhersehbaren Abstürzen (die auch nur auf bestimmten Geräten auftreten ... manchmal).

Um die symbolisierte Rückverfolgung zu erhalten, habe ich adb logcat und ndk-stack kombiniert
Zum Beispiel das Targeting von RN 059 Stock JSC ([email protected]) und 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

Gibt es ein Update zu diesem Thema?

Das Entfernen von 64-Bit ist keine Lösung gemäß Google Play 64 bit support policy. Dies kann sich möglicherweise auf Apps auswirken, die nach 1 August 2019 live @hramos irgendein Update dazu? Bitte machen Sie auf sich aufmerksam.

Hallo allerseits, ich habe das gleiche Problem in 0.59.8,
Wir möchten eine angemessene Lösung für dieses Problem haben.

Hallo,
Ich helfe beim JSC-Absturzproblem und bin auch ein Mitarbeiter von jsc-android-buildcripts.
RN 0.59 JSC stammt tatsächlich aus jsc-android-buildcripts .

Um das Absturzproblem zu beheben, benötigen wir die Absturzrückverfolgung.
Hoffentlich folgen Sie bitte den Schritten, um die Rückverfolgung zu erhalten und hier zu posten.
Ich könnte dann nachgehen, um mögliche Lösungen zu finden.

Installieren Sie ndk-build und führen Sie die folgenden Befehle aus:

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

Es scheint, dass viel Absturz von Samsung S7 kommt. Leider habe ich keine S7 zur Hand.
Hoffentlich erhalten Sie nützliche Informationen zur weiteren Fehlerbehebung.

@marlonchalegre

@Kudo Dies ist das Protokoll, mit dem ich diese Befehle für ein 0.59.8
Ich habe versucht, Debug- und Release-Builds zu erstellen und den JSC selbst anhand der Protokolle zu kompilieren.

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

Ich habe eine S7 zur Hand und würde gerne versuchen, etwas anderes auszuführen, um dies herauszufinden.

Mein Vorschlag ist, die JSC mit deaktivierter JIT neu zu kompilieren. Es ist möglich, dass die Sicherheitsmechanismen im Betriebssystem die JITs stören
Operationen auf unvorhersehbare Weise.

Ich habe die gleichen Absturzprotokolle wie @MalcolmScruggs reproduziert. Auf einer S7 - Android 7.1.2 - LineageOS 14.1.

Auf RN 0.59.8 und der neuesten Version des Hauptzweigs .

Keine Änderungen erforderlich, um den Absturz zu reproduzieren. Die Standard-RN-Vorlage löst nach einigem Tippen auf den Bildschirm einen Absturz aus.

Repo hier - https://github.com/AndrewJack/jsc_crash/tree/rn_master_branch
Absturzprotokolle befinden sich in der

Nächste Schritte: Erstellen Sie eine eigene Version von JSC mit deaktivierter JIT

Wenn jemand eine S7 auf einer neueren Version von Android hat und ein Downgrade durchführen möchte. Das habe ich getan:

Laden Sie diese Software herunter:

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

1. Installieren Sie die TWRP-Wiederherstellung (mit odin [erfordert Windows] oder einer anderen Methode)
2. Starten Sie die Wiederherstellung
3. Speicher montieren
4. Kopieren Sie das LineageOS rom & gapps-Paket
5. Installieren Sie Flash LineageOS und gapps Images
6. Neustart.

Mit dem neuesten reaktiven nativen Master und der Verwendung von @Kudos Gabel kann ich den Absturz nicht reproduzieren.

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

@ AndrewJack Erstaunlich, du hast meine experimentierten Builds so schnell gefunden.
Vielen Dank für Ihr Feedback und gut zu wissen, dass diese Versionen den Absturz für Sie behoben haben.

Lieber S,

Ich hatte zwei experimentierte JSC-Versionen. Bitte versuchen Sie, ob diese Abstürze für Sie beheben können.
Ein kurzer Schritt hier:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Eine experimentierte Version besteht darin, eine Art von JIT zu deaktivieren.
Und der andere deaktiviert JIT vollständig von @matthargett empfohlen.
Wenn die beiden Versionen den Absturz für Sie beheben, geben Sie uns bitte auch eine Rückmeldung zur Gesamtleistung und zum TTI, wie in meinem Kern erwähnt.

@ Kudo Danke für die! Was wissen Sie über die gleichzeitige GC in diesen Builds? Ich habe irgendwo erwähnt, dass dies ein weiterer Unterschied zur 32-Bit-Version ist, aber natürlich kann ich diesen Kommentar nicht mehr finden. Möglicherweise ist es eine andere Sache, die es wert ist, mit Abstürzen zu spielen, die bestehen bleiben.

@wbercx Meinst du gleichzeitige GC oder gleichzeitige JS (gleichzeitige JIT)?
Standardmäßig ist die gleichzeitige GC nur für arm64 und x64 aktiviert.
Concurrent GC bezieht sich möglicherweise nicht auf das Absturzproblem. Es geht wahrscheinlich um Heap-Management und nicht um JIT.

Concurrent JS ist für meine beiden Builds deaktiviert.
(Standardmäßig wird es nur für ENABLE(DFG_JIT) && USE(JSVALUE64) aktiviert.)

Übrigens ist JIT in JavaScriptCore kompliziert und ich bin kein Experte dafür.
Fühlen Sie sich frei, darauf hinzuweisen, wenn ich falsch lag.

@Kudo Ich habe Ihre experimentellen JSC-Versionen no-jit und no-dfg-jit ausprobiert und konnte den Absturz nicht reproduzieren. Dies scheint im Einklang mit dem zu stehen , was

Ich habe dies in einem Basisprojekt versucht, daher kann ich keine Auswirkungen auf die Leistung kommentieren.

Ich habe weitere Informationen, ich sehe diesen Absturz auch auf:
Samsung Galaxy S7 (Herolte), Android 7.0
Oppo F7 (CPH1819), Android 8.1

Auch am 0.58.5 passiert. Galaxy S7. Android 6.0. Das Einstellen auf 32-Bit-Build funktioniert ebenfalls nicht.

Der Absturz ereignet sich auch hier noch, nachdem auf 32 Bit zurückgegriffen wurde

@MalcolmScruggs Schön zu hören, dass beide experimentierten Versionen den Absturz für Sie beheben.
Ich denke, DFG_JIT zu deaktivieren, zumindest ist die JIT-Option auf alte JSC ausgerichtet.

@Kudo Planen Sie eine gezielte Deaktivierung von DFG_JIT nur für betroffene Geräte / CPUs?

Hat jemand versucht, mit der letzten Version von React Native (0.59.8) einige Abstürze zu beheben (siehe Versionshinweis)?
https://github.com/facebook/react-native/releases

Hat jemand versucht, mit der letzten Version von React Native (0.59.8) einige Abstürze zu beheben (siehe Versionshinweis)?
https://github.com/facebook/react-native/releases

In meinem Fall, in dem ich 0,59,8 verwendet habe, bin ich seitdem auf 0,57,8 zurückgekehrt, da sonst nichts zu funktionieren schien. Dieser Fehler ist besonders schlimm, da die App beim Öffnen sofort abstürzt. Meine App hat in den Bewertungen einen ziemlichen Haarschnitt gemacht.

Diese Geräte haben einen Signal-11-Absturz, aber es wird nur ein Speicherort angezeigt.

Allgemeines 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

Diese Geräte scheinen mit einem Fehler angezeigt zu werden , der wie == / lib / arm64 / libjsc.so . Ich weiß nicht genug über das Innenleben, um zu wissen, was das bedeutet, aber hoffentlich hilft es.

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

Ich kann der Liste von @ harryt2 einige Geräte hinzufügen.

Signal 11 Absturz mit nur einem Speicherort:

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
...
Die Liste wird mit ~ 65 verschiedenen Geräten und einer Android-Version zwischen 7.0 und 9.0 fortgesetzt.

Der Fehler tritt bei diesen Geräten nicht immer auf. Dies ist jedoch ein echtes Problem, da sich die in Google Play gemeldete Absturzrate meiner Anwendung nach dem Update von 0,57,8 auf 0,59,5 von 0,16% auf 1,02% geändert hat.

0,57,8:

0,59,5:

Ich bin kein Experte für Android-Entwicklung und verstehe auch nicht, woher dieser Absturz kommt. Ich kann weitere Daten bereitstellen, wenn dies hilfreich ist.

@ntorion in unserem Projekt sehen wir immer noch diese Abstürze auf Samsung s7 mit reaktionsnativen 0,59,8, fürchte ich.

Gibt es derzeit eine Lösung dafür?
Ich habe in zwei verschiedenen Galaxy Note 9 getestet, jedes Telefon stürzt sofort ab

{"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 Verwenden Sie die @ Kudo- Anweisung https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

@matpaul @Kudo Ich kann bestätigen, dass dieser experimentelle Build von js core das Problem auch für uns zu beheben scheint (getestet auf Samsung s7).

Meine Abstürze im Zusammenhang mit dieser Ablaufverfolgung gingen unter Android verloren, als ich auf 0.58.6 heruntergestuft habe. Ich hatte vor, ein Downgrade auf 57.6 , aber 58.6 scheint dies für mich behoben zu haben (obwohl es einige andere Android-Probleme gibt, die ich abmildern musste, da ich sie manuell für die Veröffentlichung erstellen muss).

@ Kudo

Lieber S,

Ich hatte zwei experimentierte JSC-Versionen. Bitte versuchen Sie, ob diese Abstürze für Sie beheben können.
Ein kurzer Schritt hier:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Eine experimentierte Version besteht darin, eine Art von JIT zu deaktivieren.
Und der andere deaktiviert JIT vollständig von @matthargett empfohlen.
Wenn die beiden Versionen den Absturz für Sie beheben, geben Sie uns bitte auch eine Rückmeldung zur Gesamtleistung und zum TTI, wie in meinem Kern erwähnt.

@Kudo Ich hatte hier zwei Beobachtungen, wie auch in Ihrem Kern erwähnt

• Die App hängt mit der Abhängigkeit von @kudo-ci/jsc-android@241213-no-dfg-jit , wenn Sie eine unserer Produktions-Apps für einige Minuten verwenden.
• App funktioniert gut mit @kudo-ci/jsc-android@241213-no-jit Abhängigkeit as of now und TTI bleibt im Vergleich zu früheren Builds gleich / unbemerkt.

Kudo, wird Ihre Pull-Anfrage ausreichen, um dies zu beheben, da ich das Hängen der App beim Testen gegen no_dfg_jit bemerkt habe

Noch ein Update hier:
Ich bezweifle wirklich, dass es andere Anwendungen geben sollte, die mit solchen Problemen konfrontiert sind, wenn der native Absturz auf S7 Edge leicht auftritt.
Erwischt!
Google Play Service mit Text-API hatte diese Probleme, aber keine OSS-Korrektur
Mono hat ein Absturzproblem bei S7 Exynos bit.LITTLE gefunden und hier ist das Update .

JavaScriptCore hat in ARM64Assembler __clear_cache verwendet.
Ich werde später in dieser Woche einen weiteren experimentierten Build zum Patchen von __clear_cache haben.

Die experimentierten Builds, die __clear_cache behoben haben, sind fertig.

Die Schritte sind dieselben wie zuvor, jedoch nur, um unterschiedliche npm-Abhängigkeiten zu verwenden.

1. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-dfg' und bestätigter adb logcat mit Version 241213.8000.0 (siehe Quellcode hier )
2. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg' und bestätigter adb logcat mit Version 241213.9000.1 (siehe Quellcode hier )

Es tut mir leid, dass ich das Absturzproblem nicht erneut überprüfen kann, sondern nur, um die grundlegenden Funktionen zu überprüfen.
Bitte helfen Sie, die beiden JSC-Experimente nach Möglichkeit zu testen.
Vielen Dank und viel Glück diesmal.

cc @AndrewJack @MalcolmScruggs @tijs @ishantsagar @timhatch

@Kudo Ich habe jetzt Feedback zu Test-Builds erhalten, bei denen sowohl @kudo-ci/jsc-android@241213-fix-clear-cache-dfg als auch @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg .
Beide Test-Builds scheinen auf dem Samsung Galaxy S7 Edge / Android 7.0 bisher absturzfrei zu sein (bisher die Problemkombination)

@Kudo Ich habe sowohl @kudo-ci/jsc-android@241213-fix-clear-cache-dfg als auch @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg in einem Basisprojekt ausprobiert, in dem React-Native 0.59.8 und in beiden Versionen tritt der Absturz nicht auf. Ich habe auf einem Samsung Galaxy S7 auf Android 7.0 getestet:

[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 Ich habe die neuesten @kudo-ci/jsc-android@241213-fix-clear-cache-dfg ausprobiert, bin aber auf einem Samsung Galaxy S5 (SM-G900F) auf einen Absturz gestoßen, ähnlich dem, den wir mit dem JSC in React Native 0.59.8 hatten

Die Version ohne JIT funktionierte einwandfrei ( @kudo-ci/jsc-android@241213-no-jit ) und es gab keine Abstürze bei dieser Version, unabhängig davon, wie sehr ich die App an ihre Grenzen gebracht habe. Ich denke, wir bleiben vorerst bei diesem.

Wir verwenden ReactRootViews in einem Viewpager, daher erstellen und zerstören wir häufig reaktionsnative Instanzen, und dies scheint diesen Absturz auszulösen. Das ist wahrscheinlich der Grund, warum wir dieses Problem häufiger als die meisten anderen haben. Wir besuchen den Viewpager-Ansatz derzeit erneut, aber in der Zwischenzeit hoffe ich, dass dieses Absturzprotokoll hilfreich sein kann. (Es ist für Version 241213.8000.0 , reaktionsnativ 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>

Leider hatten wir die schon da drin.

Wir haben unsere 64-Bit-Builds aus dem Play Store gezogen. Dies hängt möglicherweise überhaupt nicht mit dem Absturz im 64-Bit-Build zusammen, aber Galaxy S7-Geräte, auf denen der armeabi-v7a-Build ausgeführt wird, stürzen jetzt wie unten beschrieben häufig ab. Sofort nach dem Start.

Ich frage mich wirklich, was an der S7 im Vergleich zu anderen Geräten so anders ist.

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)

Wir haben dies intern gesehen und festgestellt, dass einige unserer Styling-Eigenschaften bedingt null zurückgaben. Wenn Sie dies entfernen und die style-Eigenschaft nur bedingt hinzufügen, wurde eine ähnliche Ausnahme behoben. Möglicherweise ist mit einem nativen Modultyp für Sie etwas los?

@tuncaulubilge Danke für die Information.
Nur um doppelt zu bestätigen, dass Samsung S5 (SM-G900F) eine Arm-Architektur (keine Arm64-Architektur) ist, oder?
Sie können dies durch adb shell getprop ro.product.cpu.abi überprüfen
Aus Ihrem Absturzprotokoll geht hervor, dass es sich um einen Arm handelt.

Wenn ja, gehe ich davon aus, dass die Grundursache eine andere Geschichte sein sollte als hier.
Haben Sie jemals die No-Dfg-Jit-Version getestet, dh @kudo-ci/jsc-android@241213-no-dfg-jit oder @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg ?
Diese beiden Versionen sollten auf arm32 identisch sein. Sie können einfach eine der beiden Versionen testen.

@ Kudo UPDATE

Die Rückverfolgung, die über die Entwicklerkonsole für das ursprüngliche Problem gemeldet wurde (wiederholbare Abstürze beim Start der Anwendung auf [ausschließlich] Samsung S7 Edge + Android 7.0), sieht folgendermaßen aus:

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

Das ursprüngliche Problem scheint durch jeden der folgenden Builds behoben zu sein:
@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

Ich habe es jedoch zweimal geschafft, einen weiteren Absturz für den letzten ( @kudo-ci/jsc-android@241213-fix-clear-cache-dfg ) auf einem anderen Gerät und mit einem anderen Backtrace zu stimulieren:

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

Obwohl ich es geschafft habe, die Test-App zweimal mit derselben Signatur zum Absturz zu bringen, ist der Absturz nicht systematisch wiederholbar und tritt während der Navigation zwischen verschiedenen Bildschirmen in der Test-App und nicht beim Start auf. Da das entsprechende Gerät zur Hand ist, konnte ich eine vollständigere Ablaufverfolgung von dem Gerät abrufen, die wie folgt lautet:

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>

und

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>

Keine Ahnung, ob dies hilft, Crash-Debugging und Interpretation unter Android habe ich vorher noch nicht gemacht

@ Kudo Hier sind meine Ergebnisse:

Das Samsung S5 kostet armeabi-v7a . Ich habe alle 4 Alternativen ausprobiert, die Sie bereitgestellt haben, und die ohne JIT scheint die einzige sturzfreie zu sein. Das Deaktivieren von dfg reduziert die Absturzrate erheblich, aber ich könnte es trotzdem zum Absturz bringen.

Ich teste auch auf einem Pixel XL ( arm64-v8a ) und habe noch keine Abstürze auf kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg festgestellt, aber der Absturz ist auf einem High-End-Gerät schwer zu reproduzieren, da die Hauptursache zu sein scheint niedriger Speicherdruck sein.

Um zusammenzufassen:
@kudo-ci/jsc-android@241213-no-jit : Dies ist auf beiden Geräten absturzfrei
@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg : Dies stürzt auf Low-End-Geräten ab und kann auf High-End-Geräten nicht reproduziert werden
@kudo-ci/jsc-android@241213-fix-clear-cache-dfg : Dies stürzt häufiger ab als der andere Build auf einem Low-End-Gerät. (immer noch besser als die Aktie RN 59 jsc)
@kudo-ci/jsc-android@241213-no-dfg-jit : Dies ist auch auf Low-End-Geräten abgestürzt. Ich habe es nicht auf einem High-End-Gerät getestet.

Sogar der Build ohne JIT ist erheblich schneller als die Standard-JSCs. Daher planen wir die Verwendung von @kudo-ci/jsc-android@241213-no-jit und werden ihn genauer testen, um sicherzustellen, dass er produktionsbereit ist.

Vielen Dank übrigens für die Hilfe. Lassen Sie mich wissen, ob ich Ihnen weiterhelfen kann

@timhatch @tuncaulubilge Vielen Dank für Ihre großartigen systematischen Tests und Ihr Feedback.
Im Moment habe ich wirklich keine Ahnung, wie ich das Problem beheben kann.
Weder die DFG deaktivieren noch __clear_cache reparieren hilft dabei.
Darüber hinaus tritt der Absturz auch auf arm32 auf (und die Grundursache kann sich von arm64 unterscheiden).

Meiner persönlichen Meinung nach möchte ich JIT standardmäßig überhaupt deaktivieren, zumindest um sicherzustellen, dass wir zuerst ein absturzfreies JSC haben.
Übrigens @tuncaulubilge, wie haben Sie gemessen, dass @kudo-ci/jsc-android@241213-no-jit schneller ist als Aktien-JSC?
Nur neugierig, da die No-Jit-Version aufgrund des Benchmark-Ergebnisses etwas langsamer wirkt.

@Kudo Haben Sie auch die Startzeit der App und die Speichernutzung gemessen? Ich bin immer davon ausgegangen, dass diese beiden Metriken ohne JIT besser wären. Da die meisten Apps über eine hohe Benutzeroberfläche verfügen, bin ich mir nicht sicher, ob JIT in realen Apps von großem Nutzen sein wird. Daher würde ich JIT gerne deaktivieren, wenn es den Start und die Speichernutzung verbessert. Ich bin auch gespannt, ob JSC ohne JIT einen geringeren Speicherbedarf hat.

@ Kudo
Das Beheben von __clear_cache, wie Sie es in diesen Testbuilds getan haben, verbessert definitiv die Situation, aber entweder gibt es einen Nebeneffekt des Fixes oder eine komplexere Interaktion, die noch nicht offensichtlich ist. Trotzdem konnte ich die Test-App -fix-clear-cache-dfg nicht erneut zum Absturz bringen. Es kann sein, dass das Verhalten, wie @tuncaulubilge sagt, vom Speicherdruck und / oder anderen Faktoren abhängt.

Das vollständige Deaktivieren von JIT scheint die Option "Absturzfrei" zu sein. Ich habe bei dieser Option keine Leistungseinbußen festgestellt, daher wäre dies die "sichere" Option.

@Kudo zur Verdeutlichung, ich habe React-Native 0.58.6 (ohne installiertes benutzerdefiniertes JSC) mit 0.59.8 mit @kudo-ci/jsc-android@241213-no-jit verglichen.

Ich habe keine Messungen durchgeführt, aber die Leistungsverbesserung ist sehr spürbar. Ich würde erwarten, dass die no jit -Version etwas langsamer ist als die [email protected] wie Sie erwähnt haben, aber das ist im Vergleich ignorierbar. Ich würde vorschlagen, auch die Version no-jit als Standardoption zu verwenden, da die Stabilitätsverbesserungen die geringfügigen Leistungsverbesserungen, die Sie durch jit erhalten würden, stark überwiegen.

Wir verwenden Expo v32, um unsere App zu erstellen, und wir sehen diesen Fehler auf allen Android-Versionen und -Geräten.

@ tido64 TTI hat keine großen Unterschiede. Die Binärgröße reduziert sich gegenüber der Version no_dfg um ca. 1 MB. Der Speicher reduziert sich um ca. 48%.
Ich habe eine PR gesendet, um JIT vollständig zu deaktivieren, und es gibt ein Messergebnis.
https://github.com/react-native-community/jsc-android-buildscripts/pull/108

@timhatch Gut zu hören, dass das Beheben von __clear_cache ein wenig hilft.
Ich bezweifle immer noch, dass die Hauptursache von big.LITTLE stammt, aber ich habe noch keinen anderen JSC-Code gefunden, der Probleme verursacht.
Sowohl Samsung S5 als auch S7 sind groß. LITTLE und die beiden CPU-Sets haben unterschiedliche Cache-Zeilengrößen.
Das ist vielleicht der Grund, warum ich den Absturz auf dem Samsung Note 5 nicht reproduzieren konnte, weil die Cache-Zeilengröße mit zwei CPUs beide 64B beträgt.
Ich bin mir nicht sicher, ob OS Scheduler und JSC zur Laufzeit zwischen einer großen <-> LITTLE-CPU wechseln können.
Wenn dies zutrifft, kann das Problem insbesondere zu diesem Zeitpunkt auftreten.

@tuncaulubilge Das ist neugierig für mich.
Sie könnten meine PR überprüfen, die No-Jit-Version ist langsamer als Standard RN058 JSC.
Das habe ich auch während der Messung gefühlt.
Vielleicht sind die Benchmarks Extremfälle und ziemlich anders als früher eine RN-App.
Übrigens habe ich gesehen, dass sich die Binärgröße und die Speichergröße gegenüber der No-Jit-Version verringert haben.
Diese beiden Vorteile und die Absturzfreiheit sind für mich vernünftiger.

Dieser Code rettet Leben

@RomanovYurii Wenn wir die 64-Bit-ndk-Filter "arm64-v8a" entfernt haben, bietet "x86_64" von ndk abiFilters im defaultConfig-Block von build.gradle nur 32-Bit-Unterstützung. Der Absturz ist verschwunden, aber gemäß dem 64-Bit-Support-Mandat von Google muss dies mit 64-Bit-ndk-Unterstützung behoben werden.

25060

@dishantwalia @Kudo deaktiviert JIT funktioniert für mich auf 64-Bit und sieht bisher keine Leistungsprobleme.

Dieser Kern funktionierte für mich https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Lieber S,

Wir haben das No-JIT-JSC in jsc-android npm veröffentlicht und ich habe meinen vorherigen Inhalt überarbeitet, um jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Hoffentlich, um alle Absturzprobleme zu beheben.
Wenn es keinen signifikanten Leistungsabfall gibt, werden wir die No-JIT-Version offiziell als @latest- Version vorschlagen und eine PR senden, damit sie in eine neuere RN integriert wird.

Lieber S,

Wir haben das No-JIT-JSC in jsc-android npm veröffentlicht und ich habe meinen vorherigen Inhalt überarbeitet, um jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Hoffentlich, um alle Absturzprobleme zu beheben.
Wenn es keinen signifikanten Leistungsabfall gibt, werden wir die No-JIT-Version offiziell als @latest- Version vorschlagen und eine PR senden, damit sie in eine neuere RN integriert wird.

Danke @Kudo disable -jit funktioniert bei uns wie ein Zauber !!!

Danke @Kudo für die harte Arbeit! 241213.2.0 scheint die Abstürze für uns behoben zu haben. Leider sind die Auswirkungen auf die Leistung ziemlich bedeutend. Bei Low-End-Geräten auf einigen unserer geschäftigeren Bildschirme ist die Geschwindigkeit von js fps um 20 bis 30% gesunken.

Ich kann auch bestätigen, dass die Abstürze verschwunden sind, aber wir sehen auch eine ziemlich schlechte Leistung bei Geräten der unteren Preisklasse. Ich muss sagen, es ist äußerst enttäuschend, wenn man bedenkt, dass wir auf ein Upgrade auf RN58 / RN59 für das modernere JSC gewartet haben.

@kudo Worst-Case-Szenario Das JIT sollte nur für die 64-Bit-Version deaktiviert werden, nur 64-Bit-fähige Geräte stürzen ab

@yenda Wenn dieser Build zum Fix wird, wäre es schön, diese Option ja zu haben. Ich bin mir nicht sicher, wie schwer es sein würde. Hoffentlich würde das nicht bedeuten, zwei Versionen des JSC zu versenden

@benoitdion @ItsNoHax Können Sie die spezifischen Geräte auflisten, auf denen Sie eine schlechte Leistung festgestellt haben? Vielen Dank!

Getestet unter anderem auf einem Nexus 5 und Samsung Tab E.

Stellen Sie für alle Googler, die ihr RN-Projekt auf 59.x aktualisieren, sicher, dass in android/app/build.gradle -> android {defaultConfig {versionName}} nicht mit der von React-Native-Code-Push angegebenen Version übereinstimmt.

Ich kämpfte ungefähr drei Tage lang um das gleiche Problem und stellte später fest, dass mein aktualisiertes React Native-Projekt auf Version 59.3 durch Code-Push mit React Native Version 5.7 aktualisiert wurde

Dies darf bei 90% der Menschen nicht der Fall sein. Aber für manche wie mich kann es Zeit sparen.

Danach danke an @Kudo. Die Absturzprobleme wurden behoben.

Huawei Honor 8X hat auch dieses Problem

Ich kann auch bestätigen, dass die Abstürze verschwunden sind, aber wir sehen auch eine ziemlich schlechte Leistung bei Geräten der unteren Preisklasse. Ich muss sagen, es ist äußerst enttäuschend, wenn man bedenkt, dass wir auf ein Upgrade auf RN58 / RN59 für das modernere JSC gewartet haben.

Hier gilt das gleiche. Altes RN auf Android war langsam und abstürzend, neues RN ist schnell und abstürzend und mit diesem Fix ist neues RN stabil und langsam. Scheint, wir können nicht alles auf Android haben. 🙈

Lieber S,

Es tut mir so leid, dass die Leistung für die No-JIT-Version schlecht war.
Und leider habe ich momentan keine Lösungen.
Es fällt mir schwer, ein Problem zu beheben, das ich nicht reproduzieren konnte.
Hoffentlich könnte jemand aus der Community helfen, das Problem zu lösen.

JSC für RN ist OSS unter https://github.com/react-native-community/jsc-android-buildscripts.
Es unterstützt das Aktivieren der Debug-Erstellung durch Kommentieren der Zeile in https://github.com/react-native-community/jsc-android-buildscripts/blob/master/scripts/start.sh#L10.
Wenn Sie gdb oder lldb anhängen, um nativ zu debuggen, gibt es möglicherweise einen Hinweis.
Der Absturz verstößt möglicherweise gegen RELEASE_ASSERT in https://trac.webkit.org/browser/webkit/releases/WebKitGTK/webkit-2.22.6/Source/JavaScriptCore/jit/JITOperations.cpp#L1067 , ist sich jedoch nicht sicher, wie das Problem abläuft an den Staat.

Vielen Dank für all Ihre Arbeit an diesem und jsc-android-buildscripts @Kudo. Es war erstaunlich, Ihren Fortschritt zu verfolgen! Können wir (die Community, die sich dieses Problem ansieht) irgendetwas tun, um zu helfen? Ich glaube, @tuncaulubilge hatte einen größtenteils stabilen

Vielleicht hat das interne Facebook-React-Native-Team JSC-Experten?

Ich habe mich gerade diesem Problem gestellt, das nur bei REAL DEVICE, LENOVO A701a48, RUNNING ANDROID 6 auftritt.
Löschen von "arm64-v8a", "x86_64" aus

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

Ich habe es gelöst, fühlte mich aber ein bisschen hackig.

Ich hoffe, es gibt bald ein Update vom RN-Team :(

Lieber S,

Hier ist wahrscheinlich mein letzter Versuch, eine neuere WebKit-Version zu verwenden.
@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg basiert auf WebKitGTK 2.24.2 mit Basis-JIT, aber ohne DFG-JIT.
Eine bemerkenswerte Änderung ist, dass das neuere WebKit das JIT-Bytecode-Format geändert hat.
Die JIT von x86 wird nicht unterstützt und die JIT-Unterstützung von armeabi-v7a kommt von der Community (Danke Igalia).
Da der Absturz nur auf arm64 auftritt, lohnt es sich immer noch, die neue Version auszuprobieren.

Die detaillierten Schritte zum Integrieren dieser Version finden Sie unter https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md.
Bemerkenswerte Änderung ist, dass 241213 -> 245459 aus der vorherigen JSC-Version und stellen Sie sicher, dass 245459.9000.0 im ADB-Protokoll enthalten ist.
Bitte helfen Sie bei der Überprüfung dieses experimentierten JSC.
Hoffentlich haben wir diesmal Glück. 🤞

@benoitdion danke für deine Ermutigung ❤️

@Kudo @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg funktioniert gut!

Kann bestätigen, dass der Absturz, der mit RN v0.59 bei Verwendung der oben genannten JSC aufgetreten ist, verschwunden ist. In Google Nexus 6 getestet, werden andere nach der Einführung bestätigt.

Vielen Dank!!

@Kudo Ich kann bestätigen, dass @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg für mich funktioniert. In Samsung Galaxy S7 SM-G930FD, das früher mit RN v0.59 aufgetreten ist und mit no-jit oder jsc-android v241213.2.0 behoben wurde, tritt kein Absturz auf.

Ich hatte noch keine Gelegenheit, diesen neuen Build zu integrieren, da mir einige andere Projektmeilensteine ​​im Weg stehen, aber ich plane dies, sobald diese aus dem Weg sind.

@Kudos ursprüngliche Builds no-dfg 99% der Abstürze behoben, die ich gesehen habe, und obwohl ich einen einzelnen Absturz stimulieren konnte, konnte ich ihn nicht wiederholen.

Ich glaube, dass @tuncaulubilge Abstürze mit den ursprünglichen no-dfg Builds reproduzieren konnte, daher wäre es interessant zu sehen, was er aus diesem neuen Build macht.

@rimzici @dishantwalia @timhatch Vielen Dank für Ihre Hilfe.

@tuncaulubilge Wenn Sie Zeit haben, können Sie bitte helfen, die neueste experimentierte Version zu überprüfen?
IIRC, nur Sie und @timhatch haben beim letzten Mal Abstürze vom " 241213 -fix-clear-cache-no-dfg" gemeldet.
Hoffentlich konnten wir die Abstürze durch die aktualisierte Version beheben.
Dankeschön.

@ 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
Habe dieses Problem nach der Integration von @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg auf ZTE Blade, Samsung S8, OnePlus 6. Nur auf Motorola Z2 Android 7.1.1 wurde mit dem Build begonnen!

@ 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
Habe dieses Problem nach der Integration von @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg auf ZTE Blade, Samsung S8, OnePlus 6. Nur auf Motorola Z2 Android 7.1.1 wurde mit dem Build begonnen!

Dies scheint mit realm zu tun zu haben. Bitte überprüfen Sie https://github.com/realm/realm-js/issues/2261#issuecomment -468691502
https://github.com/realm/realm-js/issues/2221

@Kudo Nochmals

Wir hatten Abstürze, insbesondere bei reactRootView.unmountReactApplication , was die Speicherbereinigung auslöst und zu gelegentlichen Abstürzen führt. Möglicherweise können Sie es mit einer Beispiel-App reproduzieren und ReactRootViews erstellen und zerstören.

@ 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
Habe dieses Problem nach der Integration von @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg auf ZTE Blade, Samsung S8, OnePlus 6. Nur auf Motorola Z2 Android 7.1.1 wurde mit dem Build begonnen!

Dies scheint mit realm tun zu haben. Bitte überprüfen Sie
Realm / Realm-Js # 2221

Ich danke dir sehr! Musste nur Realm auf 2.28 aktualisieren.
@ Kudo besonderer Dank. Meine App funktioniert schon richtig!

@Kudo Ich habe eine Version einer zuvor betroffenen App mit derselben Build-Konfiguration wie in früheren Tests neu erstellt, jedoch mit @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .
Bisher keine Abstürze oder Hänge - ich werde sehen, ob ich die App über das Wochenende belasten und zurückmelden kann, wenn ich auf Probleme stoße.

@timhatch Vielen Dank und bitte nehmen Sie sich am Wochenende Zeit.
Drücken Sie die Daumen, um beim nächsten Mal gute Nachrichten von Ihnen zu hören.

Ich kann nicht mit dem Patch bauen. Ich erhalte folgenden Fehler vom FBSDK:

`` ``
Aufgabe: react-native- fbsdk: compileReleaseJavaWithJavac FAILED
/ Users / waltermonecke / Documents / Code / React-Native2 / MoodPixel / Knotenmodule / React-Native-FBSDK / Android / Src / Main / Java / Com / Facebook / Reactnative / Androidsdk / FBAppEventsLoggerMod
ule. Java: 209 : Fehler: Symbol kann nicht gefunden werden
@ReactMethod (isBlockingSynchronousMethod = true)
^
Symbol: Methode isBlockingSynchronousMethod ()
Speicherort: @interface ReactMethod
Hinweis: Einige Eingabedateien verwenden oder überschreiben eine veraltete API.
Hinweis: Neukompilieren mit - Xlint: Details werden nicht mehr
Hinweis: /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java verwendet ungeprüfte oder unsichere Operationen.
Hinweis: Neu kompilieren mit - deaktiviert .
1 Fehler

FAILURE: Build mit einer Ausnahme fehlgeschlagen.
`` ``

@wmonecke Das Problem scheint mir komisch. Ich habe keine Java-Code- oder Gradle-Abhängigkeiten im JSC-AAR berührt.
Könnten Sie bitte das Problem überprüfen oder kurz beschreiben, wie Sie den Patch anwenden?
Ich denke, Sie verwenden versehentlich alte RN-Abhängigkeit und
Sie können dies mit ./gradlew :app:dependencies | grep 'com.facebook.react:react-native:' überprüfen (stellen Sie sicher, dass die zurückgegebene RN-Version Ihren Erwartungen entspricht).

Ich kann nicht mit dem Patch bauen. Ich erhalte folgenden Fehler vom 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 Sie müssen sowohl das Maven-Repository (React-Native als auch Kudo CI) hinzufügen, um es kompilieren zu können
maven {
// Alle React Native (JS, Obj-C-Quellen, Android-Binärdateien) werden ab npm installiert
URL "$ rootDir /../ node_modules / react-native / android"
}}

maven {
// Lokales Maven-Repo mit AARs und JSC-Bibliothek für Android
URL "$ rootDir /../ node_modules / @ kudo-ci / jsc-android / dist"
}}

@Kudo Keine Probleme mit @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Keine Anwendung hängt oder stürzt ab.

@Kudo Keine Probleme mit @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Keine Anwendung hängt oder stürzt ab.

@Kudo Bitte drücken Sie dieses jsc-android-buildscripts und veröffentlichen Sie eine Version. Wir können dies also in unseren Produktions-Apps https://github.com/react-native-community/jsc-android-buildscripts einführen.

@ Timhatch Super ! Besonderer Dank für Ihre Bestätigung. Wird die JSC-Änderungen bald in RN übertragen.

@dishantwalia Ja, läuft. Dankeschön.

Vielen Dank an @Kudo für all Ihre Arbeit daran. Können Sie (oder jemand anderes, der weiß, was passiert) mich bitte in die richtige Richtung für die Implementierung dieses Fixes führen (mir ist klar, dass es sich um eine laufende Arbeit handelt).

Ich bin derzeit auf RN 0.59.9. Wird mit der Einführung der Änderungen eine aktualisierte Version von RN in etwa 0,59,10 verfügbar sein, oder sollte ich stattdessen jsc-android-buildscripts als Paket eines Drittanbieters installieren und gemäß Dokumentation für 0,59x implementieren?

@Kudo Auch mit deiner letzten Version

Danke @Kudo , ich habe die gleiche Frage @jacquesdev stellt 0.59.10 oder jsc-android-buildscripts ?

@Kudo @dishantwalia
Vielen Dank! Ich hielt nur:
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" }

mit build.gradle

@ Kudo leider ist das Problem immer noch da (Galaxy S7, Android7). Ich habe @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg ausprobiert.

Ich habe auch die No-JIT-Version ausprobiert, was nicht geholfen hat. Ich habe es nicht geschafft, dass die "JavaScriptCore" -Version in adb logcat mit dem von Ihnen angegebenen grep ausgedruckt wird, und ich habe auch keine Erwähnung von JavaScriptCore im Protokoll selbst durch manuelles Suchen gesehen.

Ich kann den Absturz ziemlich häufig reproduzieren. Es stürzt nicht immer am selben Ort ab.

Hier ist der Fehler (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>

Die Rückverfolgung sagt nichts Sinnvolles aus.

Ich werde auch erwähnen, dass ich kein offizielles Android7 auf meinem Galaxy S7 habe, da es unmöglich war, ein Downgrade von Android8 durchzuführen (das Problem mit Android8 konnte nicht auftreten), sodass ich ein benutzerdefiniertes ROM finden musste, das Android7 unterstützt.

Ich untersuche den Versuch, meine eigene Debug-Version von jsc-android mit Ihrem letzten Commit für jsc-android-Buildscripts zu kompilieren, aber es wird eine Weile dauern.

Ich glaube, wir haben das gleiche Problem.

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

Mit der Android-Version:

Version | Nummer | Prozent
- | - | - -
Android 7.0 | 66 | 100,0%

Mit dem Gerät:

Gerät | Nummer | Prozent
- | - | - -
hero2lte | 26 | 39,4%
herolte | 24 | 36,4%
heroltebmc | 16 | 24,2%

Ich habe auch den Absturz des Galaxy S7 bekommen, nachdem ich RN von 0,58,6 auf 0,59,9 aktualisiert habe.

Die aktuelle npm-Version von jsc-android bringt die App immer noch zum Absturz, aber die Verwendung von @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg und der JSC-Version 245459.9000.0 den Absturz für mich auf S7 behoben.

@ChrisEelmaa Das "JavaScriptCore.Version" -Protokoll in adb logcat ist eine Möglichkeit, die Auswahl der richtigen JSC-Version zu bestätigen.
Da RN 0.59 libjsc.so eingebaut hat und pickFirst '** / libjsc.so' meiner Meinung nach nicht zuverlässig ist.

Eine alternative Möglichkeit zur Bestätigung der JSC-Version sind die folgenden Schritte:

1. entpacken Sie /path/to/app.apk
2. Zeichenfolgen jni / arm64-v8a / libjsc.so | grep -C 1 JavaScriptCore.Version

Die Ausgabe sollte ungefähr so ​​aussehen:

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

@Kudo danke für dein passiert .

Meine 2 Cent dort: Ich habe keinen jni Ordner, sondern einen lib Eins. Verwenden Sie diesen Befehl, um die Version nach dem Entpacken zu überprüfen:

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

Danke @Kudo

Ich hatte zuvor reaktionsnatives 0,58,3, ich sehe, dass die Leute die ganze Zeit 0,59 erwähnen, also habe ich mich auch für ein Update entschieden. Die Kombination von 0.59.0 und @ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg schien den Trick für mich zu tun.

Ich kann den Absturz nicht mehr produzieren.

Weiß jemand, ob ein Fix für dieses Problem in der nächsten RN-Version enthalten sein wird?

Weiß jemand, ob ein Fix für dieses Problem in der nächsten RN-Version enthalten sein wird?

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

@ Kristerkari
Nur um die Schritte zu bestätigen, die Sie befolgt haben.

Sie haben die Anweisungen hier unter https://github.com/react-native-community/jsc-android-buildscripts#for -react-native-version-059 befolgt

Aber Sie haben getauscht, anstatt "jsc-android": "241213.x.x", hinzuzufügen, Sie haben @kudo-ci/jsc-android": "^245459.9000.0 zu Ihrem package.json hinzugefügt? Haben Sie weitere Änderungen vorgenommen?

Ich sehe zum Beispiel, dass Sie in build.grade implementation "org.webkit:android-jsc:r241213" hinzufügen sollten. Muss sich diese Zeile ebenfalls ändern, und wenn ja, welche sollte es sein?

Ich erhalte immer wieder den Build-Fehler Could not find org.webkit:android-jsc:r241213. oder Could not find org.webkit:android-jsc:r245459.9000.0. Ich vermute also, dass mein Problem dort die falsche Referenz verwendet, kann aber nicht genau sagen, was es sein soll.

@jacquesdev Befolgen Sie die Schritte in diesem Handbuch: https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md

Lieber S,

Um dies mit Hilfe von [email protected] ' veröffentlicht.
Ich habe https://github.com/facebook/react-native/pull/25426 gesendet, um die aktualisierte JSC in RN zu haben.
Und @kelset hat es auch in RN 0.60 RC.
Hoffentlich konnten wir dieses Problem endlich beheben und schließen.
Rufen Sie die Leute hier besonders an, um Hilfe beim Überprüfen meiner experimentierten Versionen zu erhalten.
Wir sind so genannte RN-Community!

Danke @Kudo! Haben Sie eine Idee, ob dies eine Chance auf eine Veröffentlichung von 0.59.x hat, oder ist es wahrscheinlich, dass es nur in 0.60 liegt?

Es wäre großartig, wenn wir es in 0.59.x bekommen könnten
0.60 hat viele bahnbrechende Änderungen mit AndroidX und externen Bibliotheken.

+1 für uns, es in 0.59.x zu bekommen, würde viele Probleme für unsere lösen
Apps.

Ich möchte wegen der Android X-Unterstützung in nicht wirklich auf 0.60 umsteigen
Bibliotheken bisher.

Das pickFirst für JSC hat bei uns nicht funktioniert, muss eine unserer nativen Bibliotheken sein
verursacht ein Problem, aber es scheint immer die interne Version zu wählen.
(Sauberes Projekt hat zwar funktioniert, muss also einer unserer Mitarbeiter sein, der es verursacht)

Kirche

Am Samstag, 29. Juni 2019, 19:35 Uhr Anurag Dadheech, [email protected]
schrieb:

Es wäre großartig, wenn wir es in 0.59.x bekommen könnten
0.60 hat viele bahnbrechende Änderungen mit AndroidX und externen Bibliotheken.

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/facebook/react-native/issues/24261?
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AABPHZ2D5WUEM4S3242ZTYTP46TN3ANCNFSM4HC77RAQ
.

Hallo, kann ich wissen, wo ich dieses "@ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg "

Hallo @Kudo, danke für deine großartige Arbeit!

Im alten WebKit ohne DFG-JIT treten immer noch Abstürze auf, aber das neuere WebKit 2.24.2 ohne DFG-JIT scheint dies zu beheben. Ich frage mich, ob es sich lohnt, dieses neue WebKit mit aktiviertem DFG-JIT auszuprobieren, um die höchstmögliche Leistung zu erzielen, wenn es funktioniert.

Ich stimme einigen Kommentaren zu, bevor es besser wäre, eine 0,59,10 mit diesem Fix zu haben, da es schwieriger sein wird, auf 0,60 @Kudo @kelset @grabbou @turnrye zu aktualisieren

Habe das gleiche Problem hier,

Wir können kein Upgrade auf 0.60 durchführen, da React-Native-Maps AndroidX noch nicht unterstützen. Unsere Updates können nicht auf 0.59.X verschoben werden, da S7 & S7 plus abstürzt.

Dies ist wirklich ein Problem für Unternehmen, das von der Reaktion abhängt

Gibt es eine Problemumgehung dafür?

Ich stimme @adnkh zu , wir können jetzt kein Upgrade auf AndroidX durchführen, aber wir müssen die 0,59-Abstürze lösen.

Sie müssen kein Upgrade auf 0,60 durchführen, um das Update zu verwenden. Sie sollten in der Lage sein, den Anweisungen unter https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059 zu folgen. Die Version, die Sie installieren möchten, ist 245459.0.0 oder höher.

Hallo @benoitdion ,

Ja, es ist möglich zu konsumieren, obwohl es sich nicht in der Hauptbibliothek befindet. Tatsächlich habe ich diese Anweisungen befolgt: https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 . und es hat funktioniert

Aber ich denke nicht, dass dies eine dauerhafte Lösung ist und aufgrund der vielen Dinge, die Sie zu Ihrem Android-Projekt hinzufügen müssen, ordentlich ist. Ich denke, ein Hotfix im Haupt-RN wäre aus Entwicklersicht bequemer und löst viele Absturzprobleme auf Android Apps

Sie müssen kein Upgrade auf 0,60 durchführen, um das Update zu verwenden. Sie sollten in der Lage sein, den Anweisungen unter https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059 zu folgen. Die Version, die Sie installieren möchten, ist 245459.0.0 oder höher.

@benoitdion ja, aber es ist eine Problemumgehung, ein offizieller Fix, der als 0.59.10 veröffentlicht wurde, wäre besser.

Danke @Kudo
Verwenden Sie @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg die meisten Abstürze zu reduzieren
Aber es gibt immer noch ein paar Abstürze in der Produktion

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

👋 alle.

Wir hören Sie alle und aufgrund der Probleme, die so viele von Ihnen haben, haben wir eine letzte Patch-Version 0.59.10 erstellt, um Ihnen die neue Version des JSC zur Verfügung zu stellen.

Vielen Dank an Rückportierung auf 0,59.

Wir werden auf absehbare Zeit keine weiteren 0.59-Releases veröffentlichen, da dies eine herausfordernde und noch schwierigere Arbeit ist, da wir auch an 0.60 arbeiten (das wird auch das neue JSC haben!).

Ich werde dies schließen, da das Hauptproblem behoben wurde, aber ich würde vorschlagen, ein neues für andere Abstürze zu öffnen, die möglicherweise nach 0.59.10 auftreten.

Hervorragende Nachrichten !!

Vielen Dank an alle, besonders an @kudo !!

Am Dienstag, 2. Juli 2019, 12:29 Uhr Lorenzo Sciandra, [email protected]
schrieb:

👋 alle.

Wir hören Sie alle und wegen der Probleme, die so viele von Ihnen haben, haben wir
habe eine letzte Patch-Version von 0.59.10 erstellt, um Ihnen die neue Version von zur Verfügung zu stellen
die JSC.

Vielen Dank an https://github.com/Kudo für seine Arbeit an
Backporting auf 0,59.

Wir werden keine neuen 0.59-Releases machen, da dies eine herausfordernde Arbeit ist
schwieriger, weil wir auch an 0.60 arbeiten (das wird das neue JSC haben
zu!).

Ich werde dies schließen, da das Hauptproblem angegangen wurde, aber ich würde
Schlagen Sie vor, einen neuen für andere Abstürze zu öffnen, die möglicherweise auftreten
nach 0,59,10.

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/facebook/react-native/issues/24261?
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AABPHZ5PYT4F7ZZGQXZKKKLP5M325ANCNFSM4HC77RAQ
.

Vielen Dank für das Update! Muss ich nach dem Upgrade von react-native auf Version 0.59.10 die hier genannten Schritte noch implementieren?

Kevin,

Nach dem Upgrade auf RN 0.59.10 müssen Sie keinen der wichtigsten Punkte befolgen
Anweisungen nicht mehr.

K.

Am Mittwoch, 3. Juli 2019, 15:42 Uhr schrieb Kevin Etore, [email protected] :

Vielen Dank für das Update! Nach dem Upgrade von react-native auf Version 0.59.10
Muss ich die hier genannten Schritte noch ausführen?
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 ?

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ6H66HMI6CFMXMR4Y3P5S3DVA5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4WVM
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AABPHZ6UMO5NS4F4OZ7RWPTP5S3DVANCNFSM4HC77RAQ
.

Meine App stürzt immer noch unter Meizu M5s M612H Android OS 6 mit RN-0.59.10 ab. Ich habe ein neues Problem erstellt, wie von @kelset vorgeschlagen.

Stürzt immer noch auf Caterpillar S41 (Android 8.0) ab. Das Update hat das Problem auf allen anderen Geräten behoben. Außerdem wurde eine neue Ausgabe erstellt . Sagen Sie mir, ob dies nicht der richtige Weg ist.

Hallo Leute
Meine App stürzt auch auf einigen Android-Geräten ab, wenn sie in 64 Bit kompiliert wird

Verwenden Sie das React-Native-Elements- Paket Version 1.1.0?
Weil der Komponenten-Header meine App und auch die Avatar-Komponente zum Absturz bringt, wenn ich das Requisitensymbol oder den Titel eingebe

Kann jemand anderes überprüfen, ob ihm dasselbe passiert?

Hatten S7-Besitzer die Möglichkeit, dieses Problem mit Hermes zu testen?

Wenn ich unten verwende, stürzt die App ab und wird vom Google Play Store akzeptiert
ndk {abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"}
Wenn ich unten verwende, funktioniert die App, wird aber vom Google Play Store nicht akzeptiert
ndk {abiFilters "armeabi-v7a", "x86"}

Bitte hilft mir jemand beim Lösen

Stürzt immer noch auf Moto G7 und Pixel 2 (beide Android 9.0) mit der 64-Bit-Arm-APK ab. Es funktioniert gut mit dem 32-Bit-Arm APK.

@ afras21 - Dies liegt daran, dass der Fehler in der 64-Bit-Version vorliegt, die der Google Play Store obligatorisch macht.

@jacquesdev Danke

@ afras21 du meinst google hat die 64bit beschränkung aus dem playstore aufgehoben?

Ich habe das gleiche Problem. Wenn ich mein Projekt von 0,59,9 auf 0,60,4 aktualisiere, sollte ich das Problem beheben?

Ich habe das gleiche Problem. Ich benutze derzeit 0.59.9. Wenn ich auf 0.60.x aktualisiere, wird das Problem behoben?

Bitte versuchen Sie zuerst, ob 0.59.10 die Probleme für Sie gelöst hat.
Wenn nicht, lohnt es sich vielleicht, RN 0.60.4 zu aktualisieren und stattdessen Hermes einzuschalten.

Wiederholen Sie, was Kudo gesagt hat, geben Sie einfach mehr Kontext und fassen Sie den vorherigen Inhalt dieser Ausgabe zusammen (da es an dieser Stelle wahrscheinlich schwierig ist, so viele Kommentare zu sortieren):

Wenn Sie 0,59,9 oder weniger haben, ist dies ein verifiziertes Problem mit dem alten JSC. Es ist das Thema von Hunderten von Kommentaren oben (und in anderen Ausgaben). Das Problem tritt nicht nur bei 64-Bit auf, sondern tritt meistens bei 64-Bit auf.

0.60+ hat verschiedene wichtige Änderungen, insbesondere unter Android.

Wenn Sie dies nicht durchgehen möchten, versuchen Sie es mit 0.59.10, da das Update (wie oben beschrieben) direkt in die Version / den Build integriert ist - und das Problem in den meisten Fällen zu beheben scheint.

Es gibt immer noch Fälle, in denen es Probleme für bestimmte Telefone gibt (auf die ich auch gestoßen bin), siehe Nr. 25494. Wenn Sie dies haben, würde ich vorschlagen, Ihre Stacktraces dort zu diesem offenen Problem zu veröffentlichen. Wenn Sie jedoch sagen, dass Sie 0,59,9 haben, können Sie Ihr Problem wahrscheinlich beheben, indem Sie zu 0,59,10 gehen.

@MalcolmScruggs @ntorion @ harryt2
Hast du es gelöst? Wie zu lösen？ Danke

0.59.10 hat es für mich nicht gelöst. Ich werde versuchen, das 0.60.x-Upgrade durchzuführen

@MalcolmScruggs @ntorion @ harryt2
Hast du es gelöst? Wie zu lösen？ Danke

0.59.10 hat es auch für mich nicht gelöst. Ich kann nicht auf 0.60.x aktualisieren, da einige meiner Abhängigkeiten nicht funktionieren. Ich habe es auf Hermes kompiliert, habe aber einen großen Anstieg der ANRs gesehen (Gott sei Dank für den inszenierten Rollout). Ich sitze immer noch im Play Store mit der RN-Version 0.57.8, kann meine App jedoch aufgrund der 64-Bit-Anforderungen nicht mehr aktualisieren. Ziemlich frustriert und versucht zu entscheiden, ob die gesamte App mit einem anderen Framework neu erstellt werden soll.

@ harryt2 @rogerkerse Danke.
Meine Situation ist noch schlimmer. Die veröffentlichte Version hat Fehler, daher muss ich die 64-Anwendung aktualisieren. Ich kann dieses Problem momentan nicht lösen. Ich versuche auch zu flattern, aber nicht so schnell vollständigen Austausch.

Ich habe mir tatsächlich die Mühe gemacht, React-Native auf 0,60,5 zu erhöhen und Hermes + 64-Bit zu aktivieren (was ein Problem war, wie es ein Upgrade von React-Native immer ist), und ich habe diese Probleme immer noch auf mehreren Android-Handys (einschließlich HUAWEI MYA-L41).

Ich habe fast alles ausprobiert, was ich in anderen Threads gefunden habe, ohne viel Glück, also kann ich Ihnen sagen, dass das Reagieren von React-Native und die Verwendung von Hermes nicht alle diese Probleme behebt.

Das aktualisierte React-Native + Hermes und 64-Bit ist auf anderen Android-Geräten, auf denen ich es ausgeführt habe, erstaunlich und unsere App hat sich nie flüssiger angefühlt.

Wenn ich jedoch auf dem von mir erwähnten Gerät (Huawei) teste, stürzt es sofort ab oder nachdem die App 1-2 Sekunden lang ohne eine bestimmte Absturzmeldung geöffnet wurde, habe ich außer diesem und einem neueren Huawei keine anderen Geräte (Huawei). was perfekt funktioniert), daher kann ich Ihnen keine weiteren Informationen zu anderen Telefonen geben.

Wenn jemand mit diesem Problem Fortschritte erzielt hat oder Ideen zur genaueren Protokollierung meiner Probleme hat, ist ein Rat immer willkommen und ich bin bereit, Informationen zu diesem Problem weiterzugeben.
Vielen Dank an die Leute in diesem Thread für das Anbieten von Lösungen, aber bisher kein Glück. 🙂

@YoranRoels Haben Sie versucht, eine saubere App reag -native init erstellt wurde? Ich frage mich, ob der Absturz durch RN selbst oder eine Bibliothek oder einen Code verursacht wurde, den Sie geschrieben haben.

@armenbadalyan Danke für die schnelle Antwort.

Ich habe gerade ein neues Projekt eingerichtet und versucht, es auf dem Gerät auszuführen, und alles scheint in Ordnung zu sein. Am Ende scheint es also etwas mit meinem Setup zu sein. Gibt es eine effiziente Möglichkeit, dies zu debuggen, da mein Logcat nichts Nützliches ausspuckt, außer dass com.<our_app_id> getötet wurde?

React Native 59.10 löst es auch nicht für uns. Die App stürzt beim ersten Start immer noch ab.

@GreanBeetle Siehe https://github.com/facebook/react-native/issues/25494. Leider ist an dieser Stelle bekannt, dass dieses Problem nicht in allen Fällen behoben werden kann.

Der aktuellste Pfad ist (wie in diesem Thread) 0.60+ und Hermes.

@YoranRoels Holen Sie sich den Grabstein vom Gerät. Siehe: https://github.com/facebook/react-native/issues/24261#issuecomment -490239902

@GreanBeetle Sie können die V8-Engine unter 0.59.10 verwenden, um dieses Problem zu beheben
https://github.com/Kudo/react-native-v8

Danke @ j-wang. @manuhook wird Ihrer Lösung eine

@GreanBeetle Sie können die V8-Engine unter 0.59.10 verwenden, um dieses Problem zu beheben
https://github.com/Kudo/react-native-v8

Kann bestätigen, dass dies das Problem für uns gelöst hat. 64-Bit-Builds mit react-native-v8 auf 0.59.10 stürzen nicht mehr ab und wir können endlich wieder Updates bei Google Play veröffentlichen. Dankeschön!

Ich habe versucht, die erwähnte Tombstone-Protokollierung @ j-wang zu verwenden, aber ich habe sie nie wirklich verwendet, und es war eine immense Datei, die schwer zu lesen war, nachdem ich eine Weile gesucht hatte, schien ich keine wirklich lesbare Grundursache zu finden.

Nachdem ich den Rat von @armenbadalyan befolgt hatte , fragte ich mich, ob es am Anfang unserer App einfach nicht albern war, und als ich die Benutzeroberfläche der ersten Komponente entfernte, bemerkte ich, dass die App wieder stabil lief. Nachdem ich weiter gegraben hatte, bemerkte ich, dass eine bestimmte Komponente Probleme hatte, wenn ein Bild gerendert wurde.

In dieser Komponente besteht die Möglichkeit, dass wir null als Variable source für eine Variable react-native Image . Ich habe eine Weile gebraucht, um danach zu suchen und keine wirklich eindeutigen Fehler zu machen, aber dies hat endlich alles für mich behoben und läuft auf allen unseren Testgeräten. Immer noch keine Ahnung, warum es auf unserem anderen Testgerät nicht fehlgeschlagen ist ...

Könnte anderen Leuten helfen, die erste Komponente ihrer App zu vereinfachen, um sicherzustellen, dass sie nicht mit diesem Code abstürzt.

TL; DR : Dies ist wahrscheinlich mittlerweile völlig unangebracht, aber für wen es sich handelt: VERWENDEN SIE NICHT null ALS source VARIABLE VON Image , das tut es nicht. Nicht auf allen Geräten funktionieren. 😅

@ harryt2 ja, ich auch. Nach dem Upgrade auf RN 0.60. + Habe ich einen großen Anstieg der ANRs erhalten

Eine kleine Hilfe für diejenigen, die immer noch versuchen, den Startabsturz zu beheben:

1. Führen Sie adb logcat in einer Konsole aus
2. Warten Sie, bis der Konsolen-Spam beendet ist
3. Öffnen Sie die Absturz-App auf Ihrem Gerät
4. Stoppen Sie den ADB-Logcat mit Strg + C.
5. Scrollen Sie nach oben und finden Sie den Absturz

Es löst das Problem nicht, aber Sie können etwas mehr herausfinden. Ich habe 2 Apps, eine funktioniert gut mit 64-Bit und die andere hat immer noch Probleme, auch wenn sie dieselbe Konfiguration haben. Mein abstürzendes Gerät ist ein One Plus 5t (64 Bit)

Ich habe dies gerade in einer neuen Version unserer App gesehen, die mit RN 59.10 erstellt wurde, insbesondere auf einem Samsung Galaxy Note9 unter Android 9. Hat noch jemand ein ähnliches Problem gesehen?

@msspshaw Wie oben und in der anderen Ausgabe erwähnt, ja. Das neue JSC friert auf bestimmten Android-Geräten nach dem Zufallsprinzip ein / stürzt ab, da nicht deterministisch Müll gesammelt wird. Dann stürzt die gesamte App ab.

Die Lösung besteht darin, auf 0.60+ zu aktualisieren und Hermes zu verwenden oder JSC für Version 8 auszutauschen.

Ich habe versucht, die erwähnte Tombstone-Protokollierung @ j-wang zu verwenden, aber ich habe sie nie wirklich verwendet, und es war eine immense Datei, die schwer zu lesen war, nachdem ich eine Weile gesucht hatte, schien ich keine wirklich lesbare Grundursache zu finden.

Nachdem ich den Rat von @armenbadalyan befolgt hatte , fragte ich mich, ob es am Anfang unserer App einfach nicht albern war, und als ich die Benutzeroberfläche der ersten Komponente entfernte, bemerkte ich, dass die App wieder stabil lief. Nachdem ich weiter gegraben hatte, bemerkte ich, dass eine bestimmte Komponente Probleme hatte, wenn ein Bild gerendert wurde.

In dieser Komponente besteht die Möglichkeit, dass wir null als Variable source für eine Variable react-native Image . Ich habe eine Weile gebraucht, um danach zu suchen und keine wirklich eindeutigen Fehler zu machen, aber dies hat endlich alles für mich behoben und läuft auf allen unseren Testgeräten. Immer noch keine Ahnung, warum es auf unserem anderen Testgerät nicht fehlgeschlagen ist ...

Könnte anderen Leuten helfen, die erste Komponente ihrer App zu vereinfachen, um sicherzustellen, dass sie nicht mit diesem Code abstürzt.

TL; DR : Dies ist wahrscheinlich mittlerweile völlig unangebracht, aber für wen es sich handelt: VERWENDEN SIE NICHT null ALS source VARIABLE VON Image , das tut es nicht. Nicht auf allen Geräten funktionieren. 😅

+1 Funktioniert für mich. Ich hatte die gleichen Probleme. Dankeschön!

Sehen Sie es auch auf einem Samsung Galaxy S7 IO-IL 086 unter Android 7.0 RN 0.59.10

@BracketMan Verwenden Sie V8 anstelle von JSC?

@EmilScherdin ahhh nein, das bin ich nicht. Ich werde es versuchen und mich zurückmelden, danke.

@EmilScherdin Ich kann bestätigen, dass das Laufen auf V8 auf RN 0.59.10 für mich funktioniert, keine Abstürze mehr.

Vielen Dank!

Wir haben das gleiche Problem bei RN 0.59.10 mit v8. Ich sehe, dass JIT für arm64-v8a nicht deaktiviert ist und auf Geräten mit dieser Architektur Abstürze auftreten.

@mmamoyco Hast du die Stapelspur des Absturzes von V8?

@Kudo Ja, ich habe das

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)

Wir hatten genau dieses Problem mit 0.59.1 und konnten es wie folgt beheben:

⛄️ Diese Anweisungen stimmen nicht mit denen in der jsc-android README überein . Wir haben die Versionsnummern und einige Signifikanten geändert. Die canary Version von jsc behebt das Problem nicht. Es ist die Version nach jsc-android @ canary , die benötigt wird, siehe: Dieser Patch für das ursprüngliche Update, das mit dem @ ravali121 für die Unterstützung bei der Lösung dieses

1. Fügen Sie jsc-android zum Abschnitt "Abhängigkeiten" in Ihrem package.json :

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

Führen Sie dann npm install oder yarn (je nachdem, welchen npm-Client Sie verwenden), damit die neue Abhängigkeit in node_modules installiert wird

1. Ändern Sie die Datei android/build.gradle , um das neue lokale Maven-Repository, das im Paket jsc-android enthalten ist, zum Suchpfad hinzuzufügen:

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. Aktualisieren Sie die build.gradle -Datei Ihrer App in android/app/build.gradle , um die JSC-Abhängigkeit hinzuzufügen. Stellen Sie sicher, dass die Abhängigkeit vor der React Native-Abhängigkeit liegt.

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. Aktualisieren Sie die build.gradle -Datei Ihrer App in android/app/build.gradle , um die erste übereinstimmende JSC-Bibliothek zu verwenden.

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

könnte jemand helfen, diese Frage zu beantworten?
https://github.com/react-native-community/jsc-android-buildscripts/issues/127

VERWENDEN SIE NICHT null ALS source VARIABLE VON Image , es funktioniert nicht auf allen Geräten. 😅

Ich hasse es, Sie nur zu zitieren, aber ich habe Ihre Lösung im Rauschen dieses Threads fast verpasst. Vielen Dank @YoranRoels !! Das hat den Tag gerettet!

Ich finde eine Online- Website für @ YoranRoels- Methode zu verwenden, die source Variable von Image bis {null} und {{ uri: null }} aber es stürzt immer noch nicht ab. Schrecklich, ich weiß nicht einmal, wie es passiert ist. Kann mir jemand helfen?

Wir hatten genau dieses Problem mit 0.59.1 und konnten es wie folgt beheben:

⛄️ Diese Anweisungen stimmen nicht mit denen in der jsc-android README überein . Wir haben die Versionsnummern und einige Signifikanten geändert. Die canary Version von jsc behebt das Problem nicht. Es ist die Version nach jsc-android @ canary , die benötigt wird, siehe: Dieser Patch für das ursprüngliche Update, das mit dem @ ravali121 für die Unterstützung bei der Lösung dieses

1. Fügen Sie jsc-android zum Abschnitt "Abhängigkeiten" in Ihrem package.json :

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

Führen Sie dann npm install oder yarn (je nachdem, welchen npm-Client Sie verwenden), damit die neue Abhängigkeit in node_modules installiert wird

1. Ändern Sie die Datei android/build.gradle , um das neue lokale Maven-Repository, das im Paket jsc-android enthalten ist, zum Suchpfad hinzuzufügen:

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. Aktualisieren Sie die build.gradle -Datei Ihrer App in android/app/build.gradle , um die JSC-Abhängigkeit hinzuzufügen. Stellen Sie sicher, dass die Abhängigkeit vor der React Native-Abhängigkeit liegt.

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. Aktualisieren Sie die build.gradle -Datei Ihrer App in android/app/build.gradle , um die erste übereinstimmende JSC-Bibliothek zu verwenden.

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

Du bist ein Lebensretter! ❤️ Ich habe drei Tage lang nach Ihrer Antwort gesucht, um diesen Code einzufügen und die jsc-android-Version auf genau die von Ihnen erwähnte zu ändern. Und es funktioniert jetzt! Der Fehler ist aufgetreten, als ich die RN-Version von 0,59 auf 0,60 aktualisiert habe. Die App war nur für den Android kaputt, ios war in Ordnung. Das Seltsamste war, dass die App erfolgreich kompiliert wurde, sodass alles gut aussah, aber als sie gestartet wurde, stürzte sie sofort ab.