Благодарим за отправку вопроса. Можете ли вы еще раз взглянуть на свое описание и убедиться, что шаблон задачи заполнен полностью?

👉 Щелкните здесь, если хотите еще раз взглянуть на шаблон отчета об ошибке.

Благодарим за отправку вопроса. Можете ли вы еще раз взглянуть на свое описание и убедиться, что шаблон задачи заполнен полностью?

👉 Щелкните здесь, если хотите еще раз взглянуть на шаблон отчета об ошибке.

Обновлено

Скриншот ошибки Logcat для справки

публикация 64-битной сплит-сборки Я также получаю этот сбой при запуске на Galaxy S7 и Galaxy S7 Edge с Android 7.0
Android Vitals показывает:
сигнал 11 (SIGSEGV), код 1 (SEGV_MAPERR) WTFCrash
обратная трассировка:
# 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 шт 000000000019e27c

на Crashlytics для тех устройств, которые я получаю:
Неустранимое исключение: com.facebook.react.common.c
Неизменяемое нарушение: возобновление работы еще не выполнено.

обходной путь только для 32-битной сборки решает эту проблему на данный момент

Я вижу те же ошибки, что и @nadavmos на Galaxy S7 под управлением Android 7.0. Приложение вылетает при запуске

Я вижу те же ошибки, что и @nadavmos на Galaxy S7 под управлением Android 7.0. Приложение вылетает при запуске

@nsantacruz вы тоже пользуетесь

@nadavmos , я не использую react-navigation . Возможно, это та же проблема, что и # 24260, поскольку эта проблема также влияет на 0.59 с Samsung S7 на Android 7.0.

@nadavmos Сбой не связан с react-navigation , на самом деле приложение аварийно завершает работу в новом проекте RN, созданном с помощью init-native init.

@hramos @mkonicek На данный момент мы можем сделать вывод, что это, похоже, проблема с последней версией RN 0.59, влияющая на сборки Android, работающие на Samsung S7 , S7 Edge после того, как мы предоставили поддержку для arm64-v8a , x86_64 , удаление их из build.gradle не приводит к сбою приложения, что потенциально может повлиять на запуск приложений после 1 August 2019 в соответствии с политикой поддержки 64-разрядной версии Google Play. Мы бы хотели, чтобы вы обратили на это внимание, пожалуйста?

Также происходит 0.58.5. Galaxy S7. Android 6.0. Установка 32-битной сборки также не работает.

Мы наблюдаем такие же сбои в 64-битных сборках RN 0.59.4 на Galaxy S7 под управлением Android 7.0. К сожалению, у нас нет доступа к этой модели устройства. На всех наших он работает нормально.

Такая же проблема с устройством Huawai P9 в следующей среде:

  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

Это трассировка стека Crashlytics, которую мы получаем:

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

Такая же проблема с Samsung Galaxy S7 на 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)

~ Добавление этого в ваш android/app/build.gradle ~ может исправить ~ (Это не так): ~

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

~ См. Https://github.com/react-native-community/jsc-android-buildscripts/pull/95~

Спасибо за попытку помочь, но решение нам не помогло.

16 апр. 2019 г., в 19:12, Эндрю Джек [email protected] написал (а):

Добавление этого в ваш android / app / build.gradle может исправить это:

PackageOptions {
pickFirst ' /libjsc.so'pickFirst ' /libc++_shared.so'
}
См. Response-native-community / jsc-android-buildscripts # 95 https://github.com/react-native-community/jsc-android-buildscripts/pull/95
Тестирую это сейчас.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/facebook/react-native/issues/24261#issuecomment-483728028 или отключите поток https://github.com/notifications/unsubscribe-auth/ AEO_1BMzddSncn2DtQeDcx_y1KIz0ZSGks5vhfaJgaJpZM4cX_xB .

Добавление этого в ваш android/app/build.gradle может исправить это:

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

См. Response-native-community / jsc-android-buildscripts # 95.

Сейчас тестирую.

@AndrewJack, у тебя это

Добавление этого в ваш android/app/build.gradle может исправить это:

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

См. Response-native-community / jsc-android-buildscripts # 95.

Сейчас тестирую.

К сожалению, они у нас уже были.

Мы вытащили наши 64-битные сборки из Play Store. Возможно, это вообще не связано с сбоем в 64-битной сборке, но устройства Galaxy S7, на которых запущена сборка armeabi-v7a, теперь часто дают сбой, как показано ниже. Сразу при запуске.

Действительно интересно, чем же S7 отличается от других устройств.

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 Это не сработало, я подумал, что исправление конфигурации jsc-android-buildscripts может сработать.

Я получаю то же исключение, и его не может поймать обработчик неперехваченных исключений. В своем приложении для Android я пробовал этот код:

Thread.setDefaultUncaughtExceptionHandler(...);

с обработчиком, который только записывает имя исключения в консоль, а затем возвращает управление обработчику по умолчанию, но этот код не был выполнен до сбоя приложения.

Я пытался выяснить, почему Crashlytics не регистрирует эти исключения. Может быть, это причина ... Я помню, что один или два раза я видел собственные сбои в моей консоли Fabric, поэтому crashlytics может регистрировать собственные сбои, но как-то не в этом случае.

@SpertsyanKM Сбой происходит на уровне ndk. Вы не увидите сбоя в консоли firebase, если не добавите библиотеку Crashlytics NDK. https://docs.fabric.io/android/crashlytics/ndk.html

Как вы выяснили, Thread.setDefaultUncaughtExceptionHandler перехватывает только исключения Java.

Я обновился до RN 0.59.5 сегодня, но вылет все еще происходит. Эта проблема еще не устранена.

Всем привет, у меня возникла такая же проблема в 0.59.5, удалите android: screenOrientation = "portrait" из AndroidManifest.xml. Меня устраивает.

@Jeijie У меня его там уже не было, но он все равно разбился.

такая же проблема на REDMI NOTE 4X Android 7.0 и 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]

Та же проблема на Galaxy S7 Edge / Android 7.0 и с тремя разными версиями React-Native: 0.58.4, 0.58.5 и 0.59.5.
На других устройствах Android сбой не обнаружен.

Единственное решение, позволяющее избежать этой проблемы в настоящее время, - это создать приложение только на 32-битной основе. Но проблема должна быть исправлена ​​к первому августа, потому что Play Store больше не принимает только 32-битные приложения.

То же самое, только в Galaxy S7 с Android <= 7.0 (а не 8.0). Происходит с тех пор, как мы включили поддержку 64 бит.

В нашей конфигурации gradle по умолчанию мы даже не поддерживаем 64-битную версию, и, тем не менее, сбои случаются.
`` ''
defaultConfig {
applicationId _applicationId
minSdkВерсия 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 
}```

Еще один здесь, я заметил, что проблема возникает и с некоторыми устройствами Mediatek.
Alcatel A5 (ELSA6)
Alcatel 1x / TCL L9 (U5A_PLUS_4G)
Некоторые другие устройства с SoC MediaTek с поддержкой x64

Здравствуй. Мы обнаружили, что:

1. ~ Исправление для удаления поддержки 64-битной версии действительно работает ~ Это устранило проблему только для некоторых из наших пользователей
2. ~ Мы попросили пользователей решить эту проблему самостоятельно, _перезапустив свой телефон_ (нет необходимости переключаться на 32-разрядное приложение) ~ У них не было такой проблемы.

Я могу подтвердить, что удаление поддержки 64-битной версии уменьшило количество отчетов о сбоях примерно на 90%.
Это до сих пор происходит с некоторыми устройствами. Но текущее "исправление" - лучшее, что я могу сделать прямо сейчас

У меня тоже возникают сбои на OnePlus 3, но удаление поддержки 64-битной версии не помогает. У меня возникают сбои с чистым проектом init-native init (также на эмуляторах при открытии APK приложения).

та же проблема s7 edge android 7.0 сбой в производстве с разделением пакета, другие кажутся в порядке
сигнал 11 (SIGSEGV), код 1 (SEGV_MAPERR)
обратная трассировка:
# 00 шт 000000000009e144
# 01 шт 00000000000a4a70

Эта проблема уже указана в репозитории webkit. Я прокомментировал это, когда обнаружил эту проблему несколько месяцев назад: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/327#issuecomment -436781890

Было бы здорово скоординировать усилия.

Примечание: в Youi мы используем RN нестандартно. Мы создаем собственную 64-битную версию JSC, поэтому мы столкнулись с этой проблемой намного раньше, до версии 0.58.

Общими факторами являются устройства Android 6.0 или 7.0 (уровни 23 и 24) и ARM 64.
Самым распространенным устройством с такой комбинацией является S7. Обновление S7 до Android 8 устраняет проблему.

Я воспроизвел сбой в 64-битном эмуляторе Android ARM, но изображения эмулятора Android ARM слишком нестабильны и содержат ошибки, чтобы работать с ними. У меня также есть S7 для отладки, который я пытаюсь понизить до Android 7, хотя Samsung не упростил это.

@kmagiera & @kudo вы недавно выпустили новую версию https://github.com/react-native-community/jsc-android-buildscripts/pull/95

@AndrewJack Новый выпуск только для исправлений безопасности WebKit и удаления libc ++ _ shared.so для https://github.com/facebook/react-native/pull/24672. Я не думаю, что это решит проблемы со сбоями.

AFAIK, есть различные типы аварий АО.
Некоторые из них относятся к операцииLinkDirectCall, как сообщалось об этой проблеме, а некоторые - к NPE как https://github.com/react-native-community/jsc-android-buildscripts/issues/84.
Большинство из них относятся к JIT.
Путь сбоя JIT трудно воспроизвести собственными силами, но также трудно устранить неполадки.
У меня есть несколько потенциальных исправлений, но я не совсем уверен, действительно ли они решат проблему сбоя.

• Одно из исправлений - отключить DFG_JIT .

• Также есть исправление из операции, связанной с восходящим потоком LinkDirectCall

• Более новая версия JSC (WebKitGTK 2.24) включает множество изменений JIT. Стоит попробовать, если обновление поможет.

ИМО, если собственное воспроизведение невозможно, альтернативой является доставка экспериментальной сборки.

Я планирую упростить обновление АО, просто yarn add jsc-android@experiment . Это должно произойти при RN 0.60.
С помощью этого механизма, по крайней мере, мы могли бы быть на шаг впереди в устранении проблем со сбоями.

С другой стороны, было бы полезно, если бы был надежный воспроизводимый код и среда.
Например, есть репо от react-native-navigation. Это очень помогает.
https://github.com/react-native-community/jsc-android-buildscripts/issues/84#issue -407898908

Сбой происходит также на Pixel 2 с Android 9, если это поможет.
Есть ли способ получить логи сбоев при запуске APK? Я буду рад помочь получить дополнительную информацию об этих сбоях, но я мало что знаю о разработке Android.

@quietbits , большая часть журналов, связанных с этими проблемами, не очень полезна, но чтобы выяснить это:

Посмотрите, когда происходит сбой, используя adb logcat - это будет выглядеть примерно так (не совсем, так как я только что извлек это из верхней части журнала, но он показывает отрывок, поэтому я указываю на него вне):

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

Также обычно говорится, что журнал записан на «надгробную плиту».

Чтобы убрать надгробие, используйте adb bugreport ./MySuperSpecialBugReport причем последняя часть, очевидно, является тем путем, по которому вы хотите его.

Он будет загружен в виде zip-архива, и вы можете распаковать его, перейти (на большинстве устройств) к: ./MySuperSpecialBugReport/FS/data/tombstones а затем вы можете открыть надгробие с помощью текстового редактора.

Опять же, учитывая характер этих сбоев, они не очень информативны. По крайней мере, у нас они обычно с mqt_js и с низким адресом указателя. Они также все еще возникают (хотя все менее и менее странно / непредсказуемо) только с 32-битными apks.

===

@ Kudo - определенно с нетерпением жду возможности легче опробовать разные компании и посмотреть, что они делают. До сих пор это было настоящей проблемой при обновлении до 0.59 с супер недетерминированными и непредсказуемыми сбоями (которые также происходят только на определенных устройствах ... иногда).

Чтобы получить символическую обратную трассировку, я объединял adb logcat и ndk-stack
Например, таргетинг на RN 059 Stock JSC (это [email protected]) и 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

Есть новости по этой проблеме?

Удаление 64-битной версии не является решением согласно Google Play 64 bit support policy. Это потенциально может повлиять на запуск приложений после 1 August 2019 . Мы хотели бы найти правильное решение этой проблемы. @hramos есть поводу ? Пожалуйста, обратите внимание.

Всем привет, у меня такая же проблема в 0.59.8,
Мы хотели бы найти правильное решение этой проблемы.

Здравствуй,
Я помогаю с проблемой сбоя АО, а также являюсь соавтором jsc-android-buildscripts.
АО РН 0.59 фактически взято из jsc-android-buildscripts .

Чтобы устранить проблему сбоя, нам нужна трассировка сбоя.
Надеюсь, следуйте инструкциям ниже, чтобы получить обратную трассировку и опубликовать здесь.
Затем я мог бы продолжить поиск возможных решений.

Установите ndk-build и выполните команды:

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

Кажется, много сбоев происходит из-за Samsung S7. К сожалению, у меня под рукой нет S7.
Надеюсь получить полезную информацию для дальнейшего устранения неполадок.

@marlonchalegre

@Kudo Это журнал, в котором я запускал эти команды в новом проекте на RN 0.59.8
Я пробовал создавать сборки для отладки и выпуска, и сам компилирование jsc по журналам выглядело одинаково в каждом случае.

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

У меня под рукой есть S7, и я с радостью попробую запустить что-нибудь еще, чтобы разобраться в этом.

Я предлагаю перекомпилировать АО с отключенным JIT. Возможно, механизмы безопасности в ОС мешают JIT
операции каким-то непредсказуемым образом.

Я воспроизвел те же журналы сбоев, что и @MalcolmScruggs. На S7 - Android 7.1.2 - LineageOS 14.1.

На RN 0.59.8 и последней версии ветки master .

Для воспроизведения сбоя никаких изменений не требуется. Шаблон RN по умолчанию вызывает сбой после небольшого нажатия на экран.

Репо здесь - https://github.com/AndrewJack/jsc_crash/tree/rn_master_branch
Журналы сбоев находятся в

Следующие шаги: создать собственную версию JSC с отключенным JIT

Если у кого-то есть S7 на более новой версии Android, и они хотят перейти на более раннюю версию. Вот что я сделал:

Загрузите это программное обеспечение:

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

1. Установите TWRP recovery (с помощью odin [требуется windows] или другим способом)
2. Загрузиться в рекавери
3. смонтировать хранилище
4. скопировать пакет LineageOS rom & gapps
5. установить flash образы LineageOS и gapps
6. перезагружать.

С последним собственным мастером реакции и использованием no_dfg_jit или no-jit из вилки @Kudo я не могу воспроизвести сбой.

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

@AndrewJack Удивительно, вы так быстро обнаружили, что мои экспериментированные сборки.
Благодарим за отзыв и приятно знать, что эти версии устранили сбой за вас.

Уважаемые,

У меня было две экспериментальные версии JSC, попробуйте, могут ли они исправить сбои для вас.
Краткие шаги здесь:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Одна из экспериментальных версий - отключить один из видов JIT.
А другой - полностью отключить JIT из рекомендованного @matthargett .
Если две версии исправят сбой для вас, пожалуйста, также сообщите нам об общей производительности и TTI, как указано в моей сути.

@Kudo Спасибо за это! Что вы знаете о параллельной сборке мусора в этих сборках? Я где-то упоминал, что это еще одно отличие от 32-битной версии, но, конечно, я больше не могу найти этот комментарий. Может быть, еще одна вещь, с которой стоит поиграть, если сбои все же сохраняются.

@wbercx Вы имеете в виду параллельный
По умолчанию одновременный сборщик мусора включен только для arm64 и x64.
Параллельный сборщик мусора может не иметь отношения к проблеме сбоя. Скорее всего, это связано с управлением кучей, а не с JIT.

Параллельный JS отключен для обеих моих сборок.
(По умолчанию он будет включен только для ENABLE(DFG_JIT) && USE(JSVALUE64) )

Кстати, JIT в JavaScriptCore сложен, и я не эксперт в этом.
Не стесняйтесь указать, был ли я неправ.

@Kudo Я пробовал ваши no-jit и no-dfg-jit экспериментальные версии JSC и не смог воспроизвести сбой. Похоже, это соответствует тому, что сообщил @AndrewJack .

Я пробовал это на базовом проекте, поэтому не могу комментировать какое-либо влияние на производительность.

У меня есть дополнительная информация, я тоже вижу этот сбой:
Samsung Galaxy S7 (Herolte), Android 7.0
Oppo F7 (CPH1819), Android 8.1

Также происходит 0.58.5. Galaxy S7. Android 6.0. Установка 32-битной сборки также не работает.

Сбой все еще происходит здесь после возврата к 32-битной версии

@MalcolmScruggs Приятно слышать, что обе экспериментальные версии исправляют сбой за вас.
Я думаю отключить DFG_JIT, по крайней мере, параметр JIT согласован со старым JSC.

@Kudo Планируете DFG_JIT только на затронутые устройства / процессоры?

Кто-то пробовал использовать последнюю версию React Native (0.59.8), которая исправляет некоторые сбои (упомянутые в примечании к выпуску)?
https://github.com/facebook/react-native/releases

Кто-то пробовал использовать последнюю версию React Native (0.59.8), которая исправляет некоторые сбои (упомянутые в примечании к выпуску)?
https://github.com/facebook/react-native/releases

В моем случае я использовал 0.59.8, с тех пор я вернулся к 0.57.8, так как больше ничего не работало. Эта ошибка особенно серьезна, поскольку приводит к сбою приложения сразу после открытия. Мое приложение сильно постриглось в обзорах.

У этих устройств есть сигнал сбоя 11, но он просто показывает расположение памяти.

General Mobile GM8 Go - Android 8.1
Motorola Moto E - Android 7.1
Samsung Galaxy A6 + - Android 8.0
Samsung Galaxy Grand Prime Pro - Android 8.0
Samsung Galaxy Tab S2 - Android 8.0
Samsung Galaxy J5 Prime - Android 8.0
Samsung Galaxy J6 - Android 8.0
Samsung Galaxy J7 Max - Android 8.1

Эти устройства, похоже, показывают ошибку, которая выглядит как == / lib / arm64 / libjsc.so . Я недостаточно знаю о внутренней работе, чтобы понять, что это значит, но, надеюсь, это поможет.

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

Могу добавить несколько устройств в список @ harryt2.

Сигнал 11 сбой только с ячейкой памяти:

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
...
Список продолжается ~ 65 различными устройствами и версией Android от 7.0 до 9.0.

Ошибка возникает не всегда на этих устройствах. Но это серьезная проблема, так как частота сбоев моего приложения в Google Play изменилась с 0,16% до 1,02% после обновления с 0,57,8 до 0,59,5.

0,57,8:

0,59,5:

Я не эксперт в разработке Android и не понимаю, откуда взялся этот сбой. Я могу предоставить еще несколько данных, если это поможет.

@ntorion в нашем проекте, мы все еще видим эти сбои на Samsung s7 с react-native 0.59.8, я боюсь.

Есть какое-нибудь решение для этого на данный момент?
Я тестировал две разные галактики Note 9, каждый телефон сразу вылетает

{"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 используйте инструкцию @Kudo https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

@matpaul @Kudo Я могу подтвердить, что эта экспериментальная сборка ядра js, похоже, решает проблему и для нас (проверено на Samsung s7).

Мои сбои, связанные с этим, исчезли на Android, когда я понизил до 0.58.6 . Планировал перейти на более раннюю версию до 57.6 , но 58.6 похоже, исправил это для меня (хотя есть некоторые другие проблемы с Android, которые мне пришлось устранить, когда мне нужно вручную собрать для выпуска)

@Kudo

Уважаемые,

У меня было две экспериментальные версии JSC, попробуйте, могут ли они исправить сбои для вас.
Краткие шаги здесь:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Одна из экспериментальных версий - отключить один из видов JIT.
А другой - полностью отключить JIT из рекомендованного @matthargett .
Если две версии исправят сбой для вас, пожалуйста, также сообщите нам об общей производительности и TTI, как указано в моей сути.

@Kudo У меня здесь было два наблюдения, которые также упоминались в вашей сути

• Приложение зависает с зависимостью @kudo-ci/jsc-android@241213-no-dfg-jit при использовании одного из наших производственных приложений в течение нескольких минут.
• Приложение отлично работает с @kudo-ci/jsc-android@241213-no-jit dependency as of now а TTI остается неизменным / незаметным по сравнению с предыдущими сборками.

Кудо, будет ли вашего запроса на вытягивание достаточно, чтобы исправить это, поскольку я заметил зависание приложения при тестировании на no_dfg_jit

Еще одно обновление здесь:
Я действительно сомневаюсь, что родной сбой происходит легко на S7 edge, другие приложения должны сталкиваться с такими проблемами.
Попался!
У службы Google Play с текстовым API были эти проблемы, но без исправления OSS
Mono обнаружил сбой в S7 Exynos bit.LITTLE arch, и вот исправление .

JavaScriptCore действительно использовал __clear_cache в ARM64Assembler.
Позже на этой неделе у меня будет еще одна экспериментальная сборка для исправления __clear_cache.

Готовы экспериментальные сборки, исправляющие __clear_cache .

Шаги такие же, как и раньше, но только для использования другой зависимости npm.

1. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-dfg' и подтвердил adb logcat с версией 241213.8000.0 ( исходный код ссылки здесь )
2. yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg' и подтвердил adb logcat с версией 241213.9000.1 ( исходный код ссылки здесь )

К сожалению, я не могу еще раз проверить проблему сбоя, но только для проверки основных функций.
Пожалуйста, помогите протестировать два эксперимента АО, если возможно.
Спасибо вам всем и желаю удачи на этот раз.

cc @AndrewJack @MalcolmScruggs @tijs @ishantsagar @timhatch

@Kudo Теперь у меня есть отзывы о тестовых сборках с использованием как @kudo-ci/jsc-android@241213-fix-clear-cache-dfg и @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg .
Обе тестовые сборки пока работают без сбоев на Samsung Galaxy S7 Edge / Android 7.0 (до сих пор проблемная комбинация)

@Kudo Я пробовал как @kudo-ci/jsc-android@241213-fix-clear-cache-dfg и @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg в базовом проекте, работающем под React-Native 0.59.8 и в обеих версиях сбоя не происходит. Я тестировал Samsung Galaxy S7 на android 7.0:

[ro.product.board]: [universal8890]
[ro.product.brand]: [samsung]
[ro.product.cpu.abi]: [arm64-v8a]
[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: [arm64-v8a]
[ro.product.device]: [herolte]
[ro.product.first_api_level]: [23]
[ro.product.locale]: [en-GB]
[ro.product.manufacturer]: [samsung]
[ro.product.model]: [SM-G930F]
[ro.product.name]: [heroltexx]

@Kudo Я пробовал последнюю @kudo-ci/jsc-android@241213-fix-clear-cache-dfg но столкнулся с аварийным отказом на Samsung Galaxy S5 (SM-G900F), похожим на тот, который был у нас с JSC в React Native 0.59.8

Версия без JIT работала отлично ( @kudo-ci/jsc-android@241213-no-jit ) и не сталкивалась с какими-либо сбоями, независимо от того, насколько я довел приложение до предела. Так что я думаю, что мы пока будем придерживаться этого.

Мы используем ReactRootViews в окне просмотра, поэтому мы довольно часто создаем и уничтожаем собственные экземпляры, и это, похоже, вызывает этот сбой. Вероятно, поэтому мы сталкиваемся с этой проблемой чаще, чем многие другие. В настоящее время мы повторно обращаемся к подходу к просмотру страниц, но пока я надеюсь, что этот журнал сбоев может быть полезен. (это для версии 241213.8000.0 , react-native 0.59.8)

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

К сожалению, они у нас уже были.

Мы вытащили наши 64-битные сборки из Play Store. Возможно, это вообще не связано с сбоем в 64-битной сборке, но устройства Galaxy S7, на которых запущена сборка armeabi-v7a, теперь часто дают сбой, как показано ниже. Сразу при запуске.

Действительно интересно, чем же S7 отличается от других устройств.

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)

Мы видели это внутренне и заметили, что некоторые из наших свойств стиля условно возвращали null. Удаление этого и только условное добавление свойства стиля устранило аналогичное исключение - может что-то происходит с собственным типом модуля для вашего?

@tuncaulubilge Спасибо за информацию.
Просто чтобы дважды подтвердить, что Samsung S5 (SM-G900F) - это архитектура arm (а не arm64), верно?
Вы можете подтвердить с помощью adb shell getprop ro.product.cpu.abi
Судя по вашему аварийному журналу, это похоже на руку.

Если это так, то я предполагаю, что первопричина должна быть в другой истории, чем здесь.
Вы когда-нибудь тестировали версию без dfg-jit, то есть @kudo-ci/jsc-android@241213-no-dfg-jit или @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg ?
Эти две версии должны быть одинаковыми на arm32, вы можете просто протестировать любую из них.

@Kudo ОБНОВЛЕНИЕ

Отслеживание исходной проблемы, полученное через консоль разработчика (повторяющиеся сбои при запуске приложения [исключительно] на Samsung S7 Edge + Android 7.0), выглядит следующим образом:

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

Исходная проблема, по-видимому, решается каждой из следующих сборок:
@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

Однако мне удавалось дважды вызвать еще один сбой для последнего из них ( @kudo-ci/jsc-android@241213-fix-clear-cache-dfg ) на другом устройстве и с другой трассировкой:

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

Хотя мне удалось дважды аварийно завершить тестовое приложение, каждый раз с одной и той же сигнатурой, сбой не является систематически повторяемым и происходит во время навигации между разными экранами в тестовом приложении, а не при запуске. Поскольку соответствующее устройство находится под рукой, я смог получить более полную трассировку с устройства, которая выглядит следующим образом:

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>

и

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>

Не знаю, помогает ли это, отладка и интерпретация сбоев на Android - это не то, что я делал раньше

@Kudo Вот мои выводы:

Samsung S5 стоит armeabi-v7a . Я пробовал все 4 альтернативы, которые вы предоставили, и вариант без jit, кажется, единственный без сбоев. Отключение dfg значительно снижает частоту сбоев, но я все равно могу его разбить.

Я также тестирую Pixel XL ( arm64-v8a ) и еще не сталкивался с какими-либо сбоями на kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg но сбой трудно воспроизвести на устройствах высокого класса, поскольку основная причина, похоже, быть низким давлением памяти.

Подводить итоги:
@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 : эта сборка дает сбой чаще, чем другая сборка на устройстве низкого уровня. (все же лучше, чем стоковая ао РН 59)
@kudo-ci/jsc-android@241213-no-dfg-jit : Это также дает сбой на устройствах низкого уровня, я не тестировал на высоком уровне.

Даже сборка без jit выполняется значительно быстрее, чем стандартные JSC, поэтому мы планируем использовать @kudo-ci/jsc-android@241213-no-jit и будем больше тестировать, чтобы убедиться, что он готов к производству.

Кстати, большое спасибо за помощь. Дай мне знать, могу ли я чем-нибудь помочь

@timhatch @tuncaulubilge Спасибо за
Прямо сейчас я понятия не имею, как исправить проблему.
Ни отключение DFG, ни исправление __clear_cache в этом не помогают.
Более того, сбой происходит и на arm32 (и основная причина может отличаться от arm64)

По моему личному мнению, я хотел бы вообще отключить JIT по умолчанию, по крайней мере, чтобы сначала убедиться, что у нас есть АО без сбоев.
Кстати, @tuncaulubilge, как вы измерили, что @kudo-ci/jsc-android@241213-no-jit быстрее, чем акции JSC?
Просто любопытно, поскольку, судя по результатам теста, версия без jit работает немного медленнее.

@Kudo Вы также измеряли время запуска приложения и использование памяти? Я всегда предполагал, что эти два показателя были бы лучше без JIT. Поскольку большинство приложений имеют большой объем пользовательского интерфейса, я не уверен, что JIT принесет большую пользу в реальных приложениях, поэтому я бы хотел, чтобы JIT был отключен, если он улучшает запуск и использование памяти. Мне также любопытно, будет ли у JSC меньше места на диске без JIT.

@Kudo
Исправление __clear_cache, как вы это делали в этих тестовых сборках, определенно улучшает ситуацию, но либо есть побочный эффект от исправления, либо более сложное взаимодействие, которое еще не очевидно. Тем не менее, я не смог снова завершить работу тестового приложения -fix-clear-cache-dfg . Возможно, как говорит @tuncaulubilge , поведение зависит от давления памяти и / или других факторов.

Полное отключение JIT, похоже, является опцией «без сбоев», я не заметил снижения производительности с этой опцией, поэтому это был бы «безопасный» выбор.

@Kudo, чтобы уточнить, я сравнивал React-Native 0.58.6 (без установленного пользовательского jsc) и 0.59.8 с @kudo-ci/jsc-android@241213-no-jit .

Я не проводил никаких измерений, но улучшение производительности очень заметно. Я ожидал, что версия no jit будет немного медленнее, чем [email protected] как вы упомянули, но это игнорируется в сравнении. Я бы посоветовал использовать версию no-jit качестве варианта по умолчанию, поскольку улучшения стабильности значительно перевешивают незначительное улучшение производительности, которое вы получите от jit.

Мы используем Expo v32 для создания нашего приложения, и мы видим эту ошибку в версиях Android и на всех устройствах.

@ tido64 TTI особых отличий не имеет. Размер двоичного файла уменьшается примерно на 1 МБ по сравнению с версией no_dfg. Память уменьшается примерно на 48%.
Я отправил PR для полного отключения JIT, и есть результат измерения.
https://github.com/react-native-community/jsc-android-buildscripts/pull/108

@timhatch Приятно слышать, что исправление __clear_cache немного помогает.
Я все еще сомневаюсь, что основная причина - big.LITTLE, но я еще не нашел другого кода JSC, который мог бы вызвать проблемы.
И Samsung S5, и S7 большие. LITTLE и два процессора имеют разный размер строки кэша.
Возможно, причина, по которой я не смог воспроизвести сбой на Samsung Note 5, заключается в том, что размер строки кеш-памяти для двух процессоров составляет 64Б.
Не уверен, что планировщик ОС и JSC могут переключаться между большим <-> LITTLE CPU во время выполнения.
Если это правда, проблема может возникнуть именно тогда.

@tuncaulubilge Мне любопытно.
Вы можете проверить мой пиар , версия без джита работает медленнее, чем стоковая RN058 JSC.
То же самое я почувствовал во время измерения.
Возможно, тесты являются крайними случаями и совсем не такими, как раньше в приложении RN.
Кстати, я видел, что двоичный размер и размер памяти уменьшаются по сравнению с версией без jit.
Эти два преимущества и отсутствие сбоев для меня более разумны.

Этот код спасает жизни

@RomanovYurii Когда мы удалили 64-битные фильтры ndk "arm64-v8a", "x86_64" из ndk, abiFilters в блоке defaultConfig build.gradle предоставили только 32-битную поддержку. Сбой исчез, но в соответствии с мандатом на поддержку 64-разрядной версии Google это необходимо исправить с помощью 64-разрядной поддержки ndk.

25060

@dishantwalia @Kudo disabled JIT работает для меня на 64-битной

Эта суть сработала для меня https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17

Уважаемые,

Мы опубликовали no-JIT JSC в jsc-android npm, и я изменил свою предыдущую суть, чтобы использовать jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Надеюсь исправить все проблемы, связанные с падением.
Если не будет значительного падения производительности, мы официально предложим версию без JIT как

Уважаемые,

Мы опубликовали no-JIT JSC в jsc-android npm, и я изменил свою предыдущую суть, чтобы использовать jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
Надеюсь исправить все проблемы, связанные с падением.
Если не будет значительного падения производительности, мы официально предложим версию без JIT как

Спасибо, @Kudo disable-jit работает для нас как шарм !!!

Спасибо @Kudo за всю тяжелую работу! 241213.2.0, похоже, устранил сбои за нас. К сожалению, влияние на производительность очень велико. На недорогих устройствах на некоторых из наиболее загруженных экранов мы наблюдали снижение js fps на 20-30%.

Я также могу подтвердить, что сбои исчезли, но мы также наблюдаем довольно низкую производительность на устройствах более низкого уровня. Должен сказать, что это крайне разочаровывает, учитывая, что мы ждали обновления до RN58 / RN59 для более современного АО.

@kudo наихудший сценарий, jit должен быть отключен только для 64-битной версии, только 64-битные устройства терпят крах

@yenda, если эта сборка действительно станет исправлением, было бы неплохо иметь эту опцию, да. Не уверен, насколько это будет сложно. Надеюсь, это не будет означать отгрузку двух версий ЗАО.

@benoitdion @ItsNoHax Можете ли вы перечислить конкретные устройства, на которых вы наблюдали низкую производительность? Спасибо!

Проверено, в том числе, на Nexus 5 и Samsung Tab E.

Для всех сотрудников Google, которые обновляют свой проект RN до 59.x, убедитесь, что в android/app/build.gradle -> android {defaultConfig {versionName}} не совпадает с вашей версией, указанной в response-native-code-push.

Я боролся около трех дней с той же проблемой, а позже обнаружил, что мой обновленный проект React Native на v59.3 обновлялся с помощью code-push, который имеет React Native v54.7

Этого не должно быть у 90% людей. Но для некоторых вроде меня это может сэкономить время.

После этого спасибо @Kudo. Исправлены проблемы с падением.

У Huawei Honor 8X тоже есть эта проблема

Я также могу подтвердить, что сбои исчезли, но мы также наблюдаем довольно низкую производительность на устройствах более низкого уровня. Должен сказать, что это крайне разочаровывает, учитывая, что мы ждали обновления до RN58 / RN59 для более современного АО.

Тоже самое. Старый RN на Android был медленным и аварийным, новый RN быстрый и аварийный, а с этим исправлением новый RN стал стабильным и медленным. Кажется, у нас не может быть всего этого на Android. 🙈

Уважаемые,

Мне очень жаль, что производительность для версии без JIT снизилась.
И извините, у меня сейчас нет решений.
Мне сложно устранить такую ​​проблему, которую я не смог воспроизвести.
Надеюсь, кто-нибудь из сообщества поможет разобраться в проблеме.

АО для RN ​​- это OSS по адресу https://github.com/react-native-community/jsc-android-buildscripts.
Он поддерживает включение отладки путем раскомментирования строки в https://github.com/react-native-community/jsc-android-buildscripts/blob/master/scripts/start.sh#L10.
Прикрепление gdb или lldb для отладки изначально, возможно, будет какая-то подсказка.
Авария может нарушить некоторую RELEASE_ASSERT в https://trac.webkit.org/browser/webkit/releases/WebKitGTK/webkit-2.22.6/Source/JavaScriptCore/jit/JITOperations.cpp#L1067 , но не знаю, в чем проблема. государству.

Спасибо за всю вашу работу и jsc-android-buildscripts @Kudo. Было потрясающе следить за твоим прогрессом! Можем ли мы (сообщество, наблюдающее за этой проблемой) чем-то помочь? Я считаю, что у @tuncaulubilge был в основном стабильный репро.

Может быть, во внутренней команде facebook react-native есть эксперты ао?

Я только что столкнулся с этой проблемой, происходит только на НАСТОЯЩЕМ УСТРОЙСТВЕ, LENOVO A701a48, ЗАПУСКАЕТСЯ ANDROID 6.
удаление "arm64-v8a", "x86_64" из

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

действительно решил это, но чувствовал себя взломанным.

Надеюсь, скоро появятся новости от команды RN :(

Уважаемые,

Вот, наверное, моя последняя попытка - использовать более новую версию WebKit.
@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg основан на WebKitGTK 2.24.2 с базовым JIT, но без DFG JIT.
Заметным изменением является то, что более новый WebKit изменил формат байт-кода JIT.
JIT x86 не поддерживается, а поддержка JIT armeabi-v7a предоставляется сообществом (спасибо, Игалия).
Так как вылет происходит только на arm64, новую версию все же стоит попробовать.

Подробные инструкции по интеграции этой версии см. В https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md.
примечательным изменением является то, что 241213 -> 245459 по сравнению с предыдущей версией JSC и убедитесь, что в журнале adb есть 245459.9000.0 .
Помогите пожалуйста проверить это опробованное тов.
Надеюсь, на этот раз нам повезет. 🤞

@benoitdion спасибо за вашу поддержку ❤️

@Kudo @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg отлично работает!

Могу подтвердить, что сбой, который происходил с RN v0.59, при использовании вышеуказанного АО, исчез. Протестировано в Google Nexus 6, остальные будут подтверждены после развертывания.

Спасибо!!

@Kudo Я могу подтвердить, что @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg тоже работает для меня. В Samsung Galaxy S7 SM-G930FD не происходит сбоев, которые происходили ранее с RN v0.59 и были исправлены с помощью no-jit или jsc-android v241213.2.0 .

У меня еще не было возможности интегрировать эту новую сборку, так как мне мешают другие вехи проекта, но я планирую сделать это, как только они исчезнут.

Исходные сборки @Kudo no-dfg исправили 99% сбоев, которые я видел, и хотя я смог стимулировать единственный сбой, я не смог его повторить.

Я считаю, что @tuncaulubilge смог воспроизвести сбои с исходными no-dfg , поэтому было бы интересно посмотреть, что он делает с этой новой сборкой.

@rimzici @dishantwalia @timhatch Спасибо за вашу помощь.

@tuncaulubilge Если у вас есть время, не могли бы вы помочь проверить последнюю экспериментальную версию?
IIRC, только вы и @timhatch в прошлый раз сообщили о 241213 -fix-clear-cache-no-dfg».
Надеюсь, мы сможем исправить сбои в обновленной версии.
Спасибо.

@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
эта проблема возникает после интеграции @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg на ZTE Blade, Samsung S8, OnePlus 6. Только на Motorola Z2 началась сборка Android 7.1.1!

@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
эта проблема возникает после интеграции @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg на ZTE Blade, Samsung S8, OnePlus 6. Только на Motorola Z2 началась сборка Android 7.1.1!

Кажется, это связано с realm пожалуйста, проверьте https://github.com/realm/realm-js/issues/2261#issuecomment -468691502
https://github.com/realm/realm-js/issues/2221

@Kudo Еще раз спасибо за отличную работу! К сожалению, я перешел в новый проект и больше не имею доступа к старому. Я постараюсь связаться с моими старыми товарищами по команде и попросить кого-нибудь попробовать.

У нас были сбои, особенно на reactRootView.unmountReactApplication , который запускает сборку мусора, что приводит к случайным сбоям. Возможно, вы сможете воспроизвести его с помощью образца приложения, создавая и уничтожая ReactRootViews.

@Kudo
Error when loading lib: dlopen failed: "/data/data/com.amiclient.qa/lib-main/librealmreact.so" is 32-bit instead of 64-bit lib hash: 28b81ed6ba5d3bb31c51509ac8150cd4 search path is /data/app/com.amiclient.qa-1/lib/arm64
эта проблема возникает после интеграции @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg на ZTE Blade, Samsung S8, OnePlus 6. Только на Motorola Z2 началась сборка Android 7.1.1!

Это похоже на realm пожалуйста, проверьте realm / realm-js # 2261 (комментарий)
область / область-js # 2221

Большое спасибо! Просто пришлось обновить царство до 2.28.
@Kudo особая благодарность. Мое приложение уже работает правильно!

@Kudo Я перестроил версию ранее затронутого приложения с той же конфигурацией сборки, что и в предыдущих тестах, но с использованием @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .
Пока нет сбоев или зависаний - я посмотрю, смогу ли я нагружать приложение в выходные, и сообщу, если у меня возникнут какие-либо проблемы.

@timhatch Большое спасибо и, пожалуйста, не торопитесь в выходные.
Скрестите пальцы, чтобы в следующий раз услышать от вас хорошие новости.

Я не могу строить с патчем. Я получаю следующую ошибку от FBSDK:

`` ''
Задача: response-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
уле. java: 209 : ошибка: не удается найти символ
@ReactMethod (isBlockingSynchronousMethod = true)
^
символ: метод isBlockingSynchronousMethod ()
Расположение: @interface ReactMethod
Примечание. Некоторые входные файлы используют или переопределяют устаревший API.
Примечание. Перекомпилируйте с - Xlint: устаревание для подробностей.
Примечание. /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java использует непроверенные или небезопасные операции.
Примечание. Перекомпилируйте с - Xlint: для получения подробной информации
1 ошибка

ОШИБКА: сбой при сборке за исключением.
`` ''

@wmonecke Мне эта проблема кажется странной. Я не касался Java-кода или зависимостей Gradle в АО «ААР».
Не могли бы вы проверить проблему или кратко описать, как вы применяете патч?
Я предполагаю, что вы случайно используете старую зависимость RN и
вы можете проверить с помощью ./gradlew :app:dependencies | grep 'com.facebook.react:react-native:' (убедитесь, что возвращенная версия RN соответствует вашим ожиданиям).

Я не могу строить с патчем. Я получаю следующую ошибку от 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, вам нужно добавить оба репозитория maven (
maven {
// Все React Native (исходники JS, Obj-C, двоичные файлы Android) устанавливаются из npm
url "$ rootDir /../ node_modules / react-native / android"
}

maven {
// Локальное репозиторий Maven, содержащий AAR с библиотекой JSC, созданной для Android
url "$ rootDir /../ node_modules / @ kudo-ci / jsc-android / dist"
}

@Kudo Нет проблем с @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Ни одно приложение не зависает и не вылетает.

@Kudo Нет проблем с @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . Ни одно приложение не зависает и не вылетает.

@Kudo Поместите это исправление в jsc-android-buildscripts и опубликуйте версию. Поэтому мы можем развернуть это в наших производственных приложениях https://github.com/react-native-community/jsc-android-buildscripts.

@timhatch Замечательно ! Особое спасибо за вашу проверку. Скоро внесет изменения в РН.

@dishantwalia Да, продолжается. Спасибо.

Спасибо @Kudo за всю вашу работу над этим. Не могли бы вы (или кто-то еще, кто знает, что происходит) просто направьте меня в правильном направлении для реализации этого исправления (я понимаю, что это работа в стадии разработки).

Я сейчас на RN 0.59.9. После развертывания изменений станет доступна обновленная версия RN, например, 0.59.10, или мне следует вместо этого установить jsc-android-buildscripts как сторонний пакет и реализовать для 0.59x согласно документации?

@Kudo Нет проблем ни с твоей последней версией. Отличная работа! 💪

Спасибо, @Kudo , у меня тот же вопрос, который задает @jacquesdev 0.59.10 или jsc-android-buildscripts ?

@Kudo @dishantwalia
Спасибо! Я только держал:
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" }

с помощью build.gradle

@Kudo, к сожалению, проблема все еще существует (Galaxy S7, Android7). Я пробовал @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .

Я также пробовал версию без JIT, которая не помогла. Мне не удалось сделать так, чтобы версия "JavaScriptCore" распечатывалась в adb logcat с использованием предоставленной вами grep, и я не видел упоминания JavaScriptCore в самом журнале, просматривая вручную.

Я могу воспроизводить сбой довольно часто. Он не всегда падает в одном и том же месте.

Вот ошибка (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>

Трассировка ничего значимого не говорит.

Я также упомяну, что у меня нет официального Android7 на моем Galaxy S7, потому что было невозможно перейти на более раннюю версию с Android8 (не могло возникнуть проблемы с Android8), поэтому мне пришлось найти пользовательский ROM, который будет поддерживать Android7.

Я пытаюсь скомпилировать мою собственную отладочную версию jsc-android, используя вашу последнюю фиксацию на jsc-android-buildscripts, но это займет у меня некоторое время.

Я считаю, что у нас та же проблема.

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

По версии Android:

Версия | Номер | Процент
- | - | -
Android 7.0 | 66 | 100,0%

По устройству:

Устройство | Номер | Процент
- | - | -
hero2lte | 26 | 39,4%
Herolte | 24 | 36,4%
геролтебмк | 16 | 24,2%

Я также получал сбой Galaxy S7 после обновления RN с 0.58.6 до 0.59.9.

Текущая версия npm jsc-android прежнему вызывает сбой приложения, но использование @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg и версии JSC 245459.9000.0 устранило сбой для меня на S7.

@ChrisEelmaa Журнал "JavaScriptCore.Version" в adb logcat - это способ подтверждения выбора правильной версии JSC.
Поскольку RN 0.59 имеет встроенный libjsc.so, а pickFirst '** / libjsc.so', на мой взгляд, ненадежен.

Альтернативный способ подтвердить версию JSC - это следующие шаги:

1. разархивировать /path/to/app.apk
2. строки jni / arm64-v8a / libjsc.so | grep -C 1 JavaScriptCore.Version

Результат должен быть примерно таким:

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

@Kudo спасибо за ваше исправление, похоже, это предотвратило ад.

Мои 2 цента: у меня нет папки jni но вместо нее есть lib поэтому используйте эту команду для проверки версии после распаковки:

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

Спасибо @Kudo

Раньше у меня была собственная версия 0.58.3, я вижу, что люди все время упоминают 0.59, поэтому я решил также обновить. Комбинация 0.59.0 и @ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg, похоже,

Я больше не могу производить крах.

Кто-нибудь знает, будет ли исправление этой проблемы в следующем выпуске RN?

Кто-нибудь знает, будет ли исправление этой проблемы в следующем выпуске RN?

https://github.com/react-native-community/jsc-android-buildscripts#for -react-native-version-060-и новее

@kristerkari
Просто чтобы подтвердить шаги, которые вы выполнили.

Вы следовали инструкциям здесь, https://github.com/react-native-community/jsc-android-buildscripts#for -react-native-version-059

Но вы поменяли местами вместо добавления "jsc-android": "241213.x.x", , вы добавили @kudo-ci/jsc-android": "^245459.9000.0 в свой package.json? Вносили ли вы какие-нибудь другие изменения?

Например, я вижу, что в build.grade вы должны добавить implementation "org.webkit:android-jsc:r241213" , должна ли эта строка также измениться, и если да, то что она должна быть?

Я продолжаю получать ошибку сборки Could not find org.webkit:android-jsc:r241213. или Could not find org.webkit:android-jsc:r245459.9000.0. Итак, я предполагаю, что моя проблема связана с неправильной ссылкой, но не могу точно сказать, что это должно быть.

@jacquesdev, следуйте https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md

Уважаемые,

Просто чтобы обновить это с помощью @kmagiera , мой патч был опубликован как [email protected] .
Я отправил https://github.com/facebook/react-native/pull/25426, чтобы обновить JSC в RN.
И @kelset тоже есть в RN 0.60 RC.
Надеюсь, мы наконец-то сможем исправить и закрыть эту проблему.
Крик людям здесь, особенно за помощь в проверке моих экспериментальных версий взад и вперед.
Мы так называемое РН-сообщество!

Спасибо @Kudo! Вы хоть представляете, есть ли у этого шанс выпустить релиз 0.59.x, или он будет только в 0.60?

Было бы здорово, если бы мы смогли получить его в 0.59.x
0.60 имеет много критических изменений в AndroidX и внешних библиотеках.

+1 для нас, включение его в 0.59.x решит множество проблем для наших
Программы.

Не очень хочу переходить на 0.60 из-за поддержки Android X в
библиотеки пока.

PickFirst для JSC не сработал для нас, должно быть, это одна из наших собственных библиотек
вызывает проблему, но, кажется, всегда выбирает внутреннюю версию rn.
(Чистый проект сработал, значит, это одна из наших причин)

Кирк

В сб, 29 июн 2019, 19:35 Анураг Дадхич, [email protected]
написал:

Было бы здорово, если бы мы смогли получить его в 0.59.x
0.60 имеет много критических изменений в AndroidX и внешних библиотеках.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ25TBIFBOI3QWMSPXLP46TN3A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFMVREXW9
или отключить поток
https://github.com/notifications/unsubscribe-auth/AABPHZ2D5WUEM4S3242ZTYTP46TN3ANCNFSM4HC77RAQ
.

Привет, могу я знать, где добавить этот "@ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg "?

Привет, @Kudo, спасибо за

В старом WebKit без DFG JIT сбои все еще происходят, но новый WebKit 2.24.2 без DFG JIT, похоже, исправляет это. Мне интересно, стоит ли пробовать этот новый WebKit с включенным DFG JIT, чтобы обеспечить максимально возможную производительность, если он работает.

Я согласен с некоторыми комментариями, прежде чем было бы лучше иметь 0.59.10 с этим исправлением, потому что будет сложнее перейти на 0.60 @Kudo @kelset @grabbou @turnrye

У вас такая же проблема,

Мы не можем обновиться до 0.60, потому что react-native-maps еще не поддерживает AndroidX, не можем подтолкнуть наши обновления до 0.59.X, потому что S7 и S7 plus вылетает.

Это действительно проблема для бизнеса, которая зависит от React-Native

Есть ли обходной путь для этого?

Я согласен с @adnkh , сейчас мы не можем обновиться до AndroidX, но нам нужно устранить сбои версии 0.59.

Вам не нужно обновляться до 0.60, чтобы использовать исправление. Вы должны быть в состоянии следовать инструкциям на странице https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. Вы хотите установить версию 245459.0.0 или выше.

Привет @benoitdion!

Да, его можно использовать, даже если его нет в основной библиотеке, на самом деле я выполнил эти инструкции https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 . и это сработало

Но я не думаю, что это постоянное решение и изящно из-за множества вещей, которые вам нужно добавить в свой проект Android, я думаю, что исправление в основном RN было бы более удобным с точки зрения разработчика, и оно решает многие проблемы с сбоями. в приложениях для Android

Вам не нужно обновляться до 0.60, чтобы использовать исправление. Вы должны быть в состоянии следовать инструкциям на странице https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. Версия, которую вы хотите установить, - 245459.0.0 или выше.

@benoitdion да, но это обходной путь, официальное исправление, опубликованное как 0.59.10, было бы лучше.

Спасибо @Kudo
Использование @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg уменьшает большинство сбоев
Но в производстве еще есть несколько сбоев

xiaomi MIX 3 XiaoMi / MIUI Android 9, уровень 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, уровень 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, уровень 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>

👋 всем.

Мы вас всех слышим, и из-за проблем, с которыми сталкиваются многие из вас, мы выпустили последний выпуск исправления 0.59.10, чтобы предоставить вам новую версию JSC.

Огромное спасибо @Kudo за его работу по обратному портированию на 0.59.

Мы не будем выпускать другие выпуски 0.59 в обозримом будущем, так как это сложная работа, и еще более трудная, потому что мы также работаем над 0.60 (в котором также будет новый JSC!).

Я собираюсь закрыть это, так как основная проблема решена, но я бы посоветовал открыть новую для других сбоев, которые могут возникнуть после 0.59.10.

Отличная новость !!

Всем спасибо, особенно @kudo !!

Вторник, 2 июля 2019 г., 12:29 Лоренцо Скиандра, [email protected]
написал:

👋 всем.

Мы вас всех слышим, и из-за проблем, с которыми сталкиваются многие из вас, мы
сделал последний выпуск патча 0.59.10, чтобы предоставить вам новую версию
АО.

Огромное спасибо @Kudo https://github.com/Kudo за его работу над
обратный перенос на 0.59.

Мы не будем выпускать новые релизы 0.59, так как это сложная работа и даже
сложнее, потому что мы также работаем над 0.60 (который будет иметь новый АО
тоже!).

Я собираюсь закрыть это, поскольку основная проблема решена, но я бы
предложить открыть новый для других сбоев, которые могут у вас возникнуть
после 0.59.10.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZZG2Z764HFNPJB7UVTP5M325A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS443DFVREXDNVWWK3TUL52HS443DFVREXDNVWWK3TUL52HS443DFMVREXDNVWWK3TUL52HS443DFVREX
или отключить поток
https://github.com/notifications/unsubscribe-auth/AABPHZ5PYT4F7ZZGQXZKKKLP5M325ANCNFSM4HC77RAQ
.

Большое спасибо за исправление! После обновления response-native до версии 0.59.10 мне все еще нужно выполнить шаги, упомянутые здесь ?

Кевин,

После обновления до RN 0.59.10 вам не нужно следовать какой-либо сути
инструкции больше нет.

K

В среду, 3 июля 2019 г., 15:42 Кевин Эторе, [email protected] написал:

Большое спасибо за исправление! После обновления response-native до версии 0.59.10,
мне все еще нужно выполнить шаги, упомянутые здесь
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 ?

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/facebook/react-native/issues/24261?email_source=notifications&email_token=AABPHZ6H66HMI6CFMXMR4Y3P5S3DVA5CNFSM4HC77RA2YY3PNVWWK3TUL52HC77RA2YY3PNVWWK3TUL52HS4DFMVREVWWK3TUL52HS4DFMVREVWWK3TUL52HS4DFMVR0VWWK3TUL52HS4DFMVRE
или отключить поток
https://github.com/notifications/unsubscribe-auth/AABPHZ6UMO5NS4F4OZ7RWPTP5S3DVANCNFSM4HC77RAQ
.

Мое приложение все еще вылетает на Meizu M5s M612H Android OS 6 с RN-0.59.10. Я создал новую проблему, как предложил @kelset .

По-прежнему вылетает на Caterpillar S41 (Android 8.0). Исправление решило проблему на всех других устройствах. Также создал новый выпуск . Скажите, если это неправильный способ.

Привет, ребята
Мое приложение также вылетает на некоторых устройствах Android при компиляции в 64-битной версии.

Вы используете пакет react -native-elements версии 1.1.0 ??
Поскольку компонент Header вызывает сбой моего приложения, а также компонент Avatar, когда я помещаю значок или заголовок опоры

Может ли кто-нибудь еще проверить, происходит ли с ними то же самое?

У кого-нибудь из владельцев s7 была возможность протестировать эту проблему с помощью Hermes?

Если я использую нижеприведенное приложение, вылетает и принимается магазином Google Play
ndk {abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"}
Если я использую приложение ниже, оно работает, но не принимается в магазине Google Play
ndk {abiFilters "armeabi-v7a", "x86"}

пожалуйста, помогите мне решить

По-прежнему вылетает на Moto G7 и Pixel 2 (оба Android 9.0) с 64-битным APK-файлом. Он отлично работает с 32-битным APK-файлом arm.

@ afras21 - это потому, что ошибка существует в 64-битной версии, которую Google Play Store делает обязательной.

@jacquesdev Спасибо, jacq, теперь они удалили обязательный и теперь он работает

@ afras21, вы имеете в виду, что Google снял ограничение на использование 64-битных файлов в игровом магазине?

У меня такая же проблема. Если я обновлю свой проект с 0.59.9 до 0.60.4, должен ли я исправить проблему?

У меня такая же проблема. Сейчас я использую 0.59.9. Если я обновлюсь до 0.60.x, проблема будет решена?

Пожалуйста, сначала попробуйте, решила ли 0.59.10 проблемы за вас.
В противном случае, возможно, стоит обновить RN 0.60.4 и вместо этого включить Hermes .

Повторение того, что сказал Кудо, просто более подробное объяснение контекста и резюмирование предыдущего содержания этого выпуска (поскольку на данном этапе, вероятно, трудно разобрать так много комментариев):

Если у вас 0.59.9 или ниже, это проверенная проблема со старым JSC. Это предмет сотен комментариев выше (и в других вопросах). Проблема не только в 64-битной, но чаще всего возникает в 64-битной.

0.60+ имеет различные критические изменения, особенно на Android.

Если вы не хотите проходить через это, попробуйте 0.59.10, поскольку исправление (как описано выше) интегрировано непосредственно в версию / сборку - и, похоже, оно решает проблему в большинстве случаев.

Есть еще случаи, когда есть проблемы с некоторыми телефонами (с которыми я тоже столкнулся), см. # 25494 - если у вас есть это, я бы посоветовал опубликовать ваши трассировки стека для этой открытой проблемы там. Однако, если вы говорите, что у вас 0.59.9, вы можете _ вероятно_ решить вашу проблему, перейдя на 0.59.10.

@MalcolmScruggs @ntorion @ harryt2
Вы решили это? Как решить？ Спасибо

0.59.10 не решил для меня. Попробую сделать апгрейд 0.60.x

@MalcolmScruggs @ntorion @ harryt2
Вы решили это? Как решить？ Спасибо

0.59.10 для меня тоже не решила. Я не могу перейти на 0.60.x, потому что некоторые из моих зависимостей не работают. Получил его для компиляции на Hermes, но увидел огромный всплеск ANR (слава Богу за поэтапное развертывание). Я все еще сижу в Play Store с версией RN 0.57.8, но я больше не могу обновлять свое приложение из-за 64-битных требований. Довольно разочарован и пытается решить, нужно ли просто перестроить все приложение с другим фреймворком.

@ harryt2 @rogerkerse Спасибо.
Моя ситуация еще хуже. В выпущенной версии есть ошибки, поэтому мне нужно обновить приложение 64. Я не могу решить эту проблему на данный момент. Тоже пробую флаттер, но не очень быструю полную замену.

На самом деле я столкнулся с проблемой повышения React-Native до 0.60.5 и включения Hermes + 64-бит (что было проблемой, поскольку обновление react-native всегда так), и у меня все еще возникают эти проблемы на нескольких телефонах Android (включая HUAWEI MYA-L41).

Я пробовал практически все, что нашел в других потоках, без особого успеха, поэтому могу сказать вам, что нативная реакция и использование Hermes не решает всех этих проблем.

Обновленная версия React-native + Hermes и 64-разрядная версия великолепны на других устройствах Android, на которых я запускал ее, и наше приложение никогда не было более плавным.

Однако всякий раз, когда я тестирую конкретное устройство, о котором я упоминал (Huawei), оно вылетает мгновенно или после открытия приложения в течение 1-2 секунд без определенного сообщения о сбое, у меня нет других устройств, кроме этого, и более нового Huawei ( который отлично работает), поэтому я не могу дать вам больше информации о других телефонах.

Если кто-то добился каких-либо успехов в решении этой проблемы или у кого-то есть идеи для более конкретной регистрации моих проблем, совет всегда приветствуется, и я готов поделиться любой информацией по этому вопросу.
Спасибо людям в этой теме за предложения решений, но пока безуспешно. 🙂

@YoranRoels Вы пробовали запустить чистое приложение, созданное с помощью init-native init? Интересно, вызван ли сбой самим RN или какой-то библиотекой или кодом, который вы написали.

@armenbadalyan Спасибо за быстрый ответ.

Я только что создал новый проект и попытался запустить его на устройстве, и все кажется хорошо, так что в конце концов это похоже на мою настройку. Есть ли эффективный способ отладить это, поскольку мой logcat не извергает ничего полезного, кроме того, что com.<our_app_id> был убит?

React Native 59.10 тоже не решает эту проблему. Приложение продолжает вылетать при первом запуске.

@GreanBeetle См. Https://github.com/facebook/react-native/issues/25494. К сожалению, на данный момент известно, что версия 0.59.10 не решает эту проблему во всех случаях.

Самый актуальный путь - использовать (как в этой ветке) 0.60+ и Hermes.

@YoranRoels Возьмите надгробие с устройства. См. Https://github.com/facebook/react-native/issues/24261#issuecomment -490239902

@GreanBeetle Вы можете использовать движок V8 на 0.59.10, чтобы избавиться от этой проблемы.
https://github.com/Kudo/react-native-v8

Спасибо @ j-wang. @manuhook попробует ваше решение.

@GreanBeetle Вы можете использовать движок V8 на 0.59.10, чтобы избавиться от этой проблемы.
https://github.com/Kudo/react-native-v8

Могу подтвердить, что это решило проблему для нас. 64-битные сборки с react-native-v8 на 0.59.10 больше не дают сбоев, и мы, наконец, можем снова отправлять обновления в Google Play. Спасибо!

Я пробовал вести журнал надгробий, упомянутый @ j-wang, но я никогда не использовал его, и это был огромный файл, который было трудно читать, после некоторого времени я, похоже, не нашел читаемой основной причины.

Послушав совет

В этом компоненте есть вероятность, что мы передадим null как переменную source в react-native Image . Мне потребовалось некоторое время, чтобы найти эту явную ошибку, но это, наконец, исправило все для меня, и оно работает на всех наших тестовых устройствах. По-прежнему не понимаю, почему он не вышел из строя на другом нашем тестовом устройстве ...

Может помочь другим людям упростить первый компонент своего приложения, чтобы избежать сбоев в этом коде.

TL; DR : Это, вероятно, сейчас совершенно не по теме, но для кого это касается: НЕ ИСПОЛЬЗУЙТЕ null КАК source ПЕРЕМЕННУЮ ОТ Image , это не так. т работать на всех устройствах. 😅

@ harryt2 да, я тоже. У меня резко выросло количество ошибок ANR после обновления до RN 0.60. +

Небольшая помощь тем, кто все еще пытается устранить сбой при запуске:

1. запустить adb logcat в консоли
2. дождитесь, пока консольный спам прекратится
3. откройте аварийное приложение на вашем устройстве
4. остановите adb logcat с помощью Ctrl + c
5. прокрутите вверх и найдите сбой

Это не решает проблему, но позволяет узнать больше. У меня 2 приложения, одно хорошо работает с 64-битной версией, но все еще борется с другим, даже если у них такая же конфигурация. Мое сбойное устройство - One Plus 5t (64 бит)

Я только что видел это в новом выпуске нашего приложения, построенном на RN 59.10, в частности, на Samsung Galaxy Note9 на Android 9. Кто-нибудь еще сталкивался с подобной проблемой?

@msspshaw Как уже упоминалось выше и в другом выпуске, да. Новый JSC зависает / аварийно завершает работу на определенных устройствах Android, потому что он получает недетерминированный сборщик мусора, а затем происходит сбой всего приложения.

Решение состоит в том, чтобы перейти на версию 0.60+ и использовать Hermes или отключить JSC для версии v8.

Я пробовал вести журнал надгробий, упомянутый @ j-wang, но я никогда не использовал его, и это был огромный файл, который было трудно читать, после некоторого времени я, похоже, не нашел читаемой основной причины.

Послушав совет

В этом компоненте есть вероятность, что мы передадим null как переменную source в react-native Image . Мне потребовалось некоторое время, чтобы найти эту явную ошибку, но это, наконец, исправило все для меня, и оно работает на всех наших тестовых устройствах. По-прежнему не понимаю, почему он не вышел из строя на другом нашем тестовом устройстве ...

Может помочь другим людям упростить первый компонент своего приложения, чтобы избежать сбоев в этом коде.

TL; DR : Это, вероятно, сейчас совершенно не по теме, но для кого это касается: НЕ ИСПОЛЬЗУЙТЕ null КАК source ПЕРЕМЕННУЮ ОТ Image , это не так. т работать на всех устройствах. 😅

+1 У меня работает. У меня были такие же проблемы. Спасибо!

Также посмотрите, как это происходит на Samsung Galaxy S7 IO-IL 086 на Android 7.0 RN 0.59.10.

@BracketMan Вы используете V8 вместо JSC?

@EmilScherdin аааа нет, я не такой. Попробую и скажу спасибо.

@EmilScherdin Я могу подтвердить, что работа на V8 на RN 0.59.10 у меня работает, сбоев больше нет.

Спасибо!

Мы сталкиваемся с той же проблемой в RN 0.59.10 с v8. Я вижу, что JIT не отключен для arm64-v8a и на устройствах с этой архитектурой у нас возникают сбои.

@mmamoyco У вас есть трассировка сбоя из V8?

@Kudo Да, у меня есть журнал сбоев. Мы перешли на v8 с jsc, потому что у нас было много сбоев. Но то же самое происходит с v8. ниже журнал

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

# 01 ПК 0000000000c3437c /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 02 ПК 0000000000c30554 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 03 ПК 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 ПК 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)

У нас была именно эта проблема в 0.59.1, и мы смогли исправить ее, выполнив следующие действия:

⛄️ Эти направления не такие, как в README jsc-android . Мы изменили номера версий и некоторые обозначения. Версия canary jsc не решает проблему. Это версия после jsc-android @ canary, которая необходима, см. Этот патч для исходного исправления, которое было объединено с репозиторием, поддерживающим реакцию. Спасибо @ ravali121 за помощь в решении этой проблемы.

1. Добавьте jsc-android в раздел "зависимости" в вашем package.json :

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

затем запустите npm install или yarn (в зависимости от того, какой клиент npm вы используете), чтобы новая зависимость была установлена ​​в node_modules

1. Измените файл android/build.gradle чтобы добавить новый локальный репозиторий maven из пакета jsc-android в путь поиска:

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. Обновите файл build.gradle своего приложения, расположенный в android/app/build.gradle чтобы добавить зависимость JSC. Пожалуйста, убедитесь, что зависимость находится перед зависимостью React Native.

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

1. Обновите файл build.gradle своего приложения, расположенный в android/app/build.gradle чтобы использовать первую совпавшую библиотеку JSC.

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

кто-нибудь может помочь ответить на этот вопрос?
https://github.com/react-native-community/jsc-android-buildscripts/issues/127

НЕ ИСПОЛЬЗУЙТЕ null КАК source ПЕРЕМЕННУЮ ОТ Image , это работает не на всех устройствах. 😅

Ненавижу просто цитировать вас, но я почти пропустил ваше решение в шуме этой беседы. Большое спасибо @YoranRoels !! Это спасло положение!

Я нахожу веб-сайт для тестирования реальной машины в Интернете, там я выбрал GALAXY S7 Edge и android 7.0 os, к сожалению, сбоев не произошло, и я пытаюсь использовать метод @YoranRoels, устанавливающий source переменную Image to {null} и {{ uri: null }} но он все еще не вылетает, Ужасно, я даже не знаю, как это произошло, Кто-нибудь может мне помочь.

У нас была именно эта проблема в 0.59.1, и мы смогли исправить ее, выполнив следующие действия:

⛄️ Эти направления не такие, как в README jsc-android . Мы изменили номера версий и некоторые обозначения. Версия canary jsc не решает проблему. Это версия после jsc-android @ canary, которая необходима, см. Этот патч для исходного исправления, которое было объединено с репозиторием, поддерживающим реакцию. Спасибо @ ravali121 за помощь в решении этой проблемы.

1. Добавьте jsc-android в раздел "зависимости" в вашем package.json :

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

затем запустите npm install или yarn (в зависимости от того, какой клиент npm вы используете), чтобы новая зависимость была установлена ​​в node_modules

1. Измените файл android/build.gradle чтобы добавить новый локальный репозиторий maven из пакета jsc-android в путь поиска:

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. Обновите файл build.gradle своего приложения, расположенный в android/app/build.gradle чтобы добавить зависимость JSC. Пожалуйста, убедитесь, что зависимость находится перед зависимостью React Native.

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

1. Обновите файл build.gradle своего приложения, расположенный в android/app/build.gradle чтобы использовать первую совпавшую библиотеку JSC.

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

Вы спасатель! ❤️ Я три дня искал ваш ответ, чтобы вставить этот код и изменить версию jsc-android на ту, которую вы упомянули. И теперь работает! Ошибка произошла, когда я обновил версию RN с 0.59 до 0.60. Приложение было сломано только на андроид, на ios все было нормально. Самым странным было то, что приложение было успешно скомпилировано, поэтому все выглядело отлично, но при запуске сразу же вылетало.