search

facebook / react-native

A framework for building native applications using React
https://reactnative.dev
MIT License
119.26k stars 24.34k forks source link

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) libjsc.so still occuring on Caterpillar S41 (Android 8.0) #25494

Closed ebaynaud closed 3 years ago

ebaynaud commented 5 years ago

Same as https://github.com/facebook/react-native/issues/24261 but still occuring on device Caterpillar S41 (Android 8.0).

React Native version: 0.59.10

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.myapp <<<

backtrace:
  #00  pc 00000000000f7748  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #01  pc 0000000000143fe8  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #02  pc 000000000012f0a8  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #03  pc 0000000000139484  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #04  pc 000000000013900c  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #05  pc 00000000001fb9c4  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #06  pc 00000000001f8e90  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #07  pc 00000000001f96bc  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #08  pc 00000000001e41a0  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #09  pc 00000000006171ec  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #10  pc 0000000000617950  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #11  pc 000000000060de7c  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #12  pc 000000000061b084  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #13  pc 0000000000646dc8  /data/app/com.myapp-Fgc_pnA5bQP7DCgIn51TQQ==/lib/arm64/libjsc.so
  #14  pc 0000000000066f34  /system/lib64/libc.so (_ZL15__pthread_startPv+36)
  #15  pc 000000000001eb94  /system/lib64/libc.so (__start_thread+68)
Kudo commented 5 years ago

@ebaynaud Do you have any reproduced steps? Otherwise, symbolicated backtrace would be helped.

wget https://registry.npmjs.org/jsc-android/-/jsc-android-245459.0.0.tgz
tar xf jsc-android-245459.0.0.tgz
unzip package/dist/org/webkit/android-jsc/r245459/android-jsc-r245459.aar

adb logcat -c
adb logcat | ndk-stack -sym jni/arm64-v8a/libjsc.so
ebaynaud commented 5 years ago

Sorry but no, I cannot reproduce by myself because I don't have this device within easy reach. The crash is coming from Google Play console.

thomasonweb commented 5 years ago

Hi Kudo,

I confirm crash is gone from Samsung devices but after upgrading to 0.59.10 we are still seeing it on a couple of other devices as well (unfortunately also through Google Play - I don't have access to such a device to reproduce).

So far I've seen it on: Asus X555 Huawei P9 Lite Huawei y6 2017 Huawei Y7 Prime 2018

Running Android 6.0, 7.0 and 8.0.

I've also seen a couple of devices running Android 9 or Android 8.1: Huawei p smart 2019 Huawei p30

As you can see, Huawei devices are standing out. I have a Huawei P smart (FIG-LX1) running android 8.0 test device myself but it seems to be running just fine on that one.


pid: 0, tid: 0 >>> live.ablo <<<

backtrace:
#00 pc 00000000000f7748 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#1 pc 0000000000143fe8 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#2 pc 000000000012f0a8 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#3 pc 0000000000139484 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#4 pc 000000000013900c /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#5 pc 00000000001fb9c4 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#6 pc 00000000001f8e90 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#7 pc 00000000001f96bc /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#8 pc 00000000001e41a0 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#9 pc 00000000006171ec /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#10 pc 0000000000617950 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#11 pc 000000000060de7c /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#12 pc 000000000061b084 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#13 pc 0000000000646dc8 /data/app/com.myapp-7flUaqbvABD7Q-kusVtsLw==/lib/arm64/libjsc.so
#14 pc 0000000000082e10 /system/lib64/libc.so (__pthread_start(void*)+36)
#15 pc 0000000000024080 /system/lib64/libc.so (__start_thread+68)
xanderdeseyn commented 5 years ago

I'm experiencing it as well on a Huawei Y5 (2017).

jsaraiva commented 5 years ago

Same here. Asus ZenFone 3 Max, Android 8.1. The stack trace (via Google Play Console) is almost exactly the same as the other ones in this issue (except for the pc for /system/lib64/libc.so, which would vary according to the device manufacturer or Android version, I guess).

pid: 0, tid: 0 >>> pt.geota.app <<<

backtrace:
  #00  pc 00000000000f7748  /data/data/pt.geota.app/lib-0/libjsc.so
  #01  pc 0000000000143fe8  /data/data/pt.geota.app/lib-0/libjsc.so
  #02  pc 000000000012f0a8  /data/data/pt.geota.app/lib-0/libjsc.so
  #03  pc 0000000000139484  /data/data/pt.geota.app/lib-0/libjsc.so
  #04  pc 000000000013900c  /data/data/pt.geota.app/lib-0/libjsc.so
  #05  pc 00000000001fb9c4  /data/data/pt.geota.app/lib-0/libjsc.so
  #06  pc 00000000001f8e90  /data/data/pt.geota.app/lib-0/libjsc.so
  #07  pc 00000000001f96bc  /data/data/pt.geota.app/lib-0/libjsc.so
  #08  pc 00000000001e41a0  /data/data/pt.geota.app/lib-0/libjsc.so
  #09  pc 00000000006171ec  /data/data/pt.geota.app/lib-0/libjsc.so
  #10  pc 0000000000617950  /data/data/pt.geota.app/lib-0/libjsc.so
  #11  pc 000000000060de7c  /data/data/pt.geota.app/lib-0/libjsc.so
  #12  pc 000000000061b084  /data/data/pt.geota.app/lib-0/libjsc.so
  #13  pc 0000000000646dc8  /data/data/pt.geota.app/lib-0/libjsc.so
  #14  pc 000000000007472c  /system/lib64/libc.so (__pthread_start(void*)+36)
  #15  pc 000000000001fbb4  /system/lib64/libc.so (__start_thread+68)
mars-lan commented 5 years ago

Seeing potentially similar issue for a variety of 64-bit phones running Android 9. RN: 0.59.10 JSC: 241213.1.0 (with ICU i18n support)

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.invisatime <<<

backtrace:
  #00  pc 00000000004ae0c0  /data/data/com.invisatime/lib-0/libjsc.so
  #01  pc 00000000004ab608  /data/data/com.invisatime/lib-0/libjsc.so
  #02  pc 00000000004abd90  /data/data/com.invisatime/lib-0/libjsc.so
  #03  pc 0000000000498004  /data/data/com.invisatime/lib-0/libjsc.so
  #04  pc 000000000088ea1c  /data/data/com.invisatime/lib-0/libjsc.so
  #05  pc 000000000088f14c  /data/data/com.invisatime/lib-0/libjsc.so
  #06  pc 000000000088527c  /data/data/com.invisatime/lib-0/libjsc.so
  #07  pc 00000000008929f0  /data/data/com.invisatime/lib-0/libjsc.so
  #08  pc 00000000008a5098  /data/data/com.invisatime/lib-0/libjsc.so
  #09  pc 0000000000081938  /system/lib64/libc.so (__pthread_start(void*)+36)
  #10  pc 0000000000023478  /system/lib64/libc.so (__start_thread+68)
xanderdeseyn commented 5 years ago

I'm seeing this on at least 5 different devices. Anyone came up with a solution?

j-wang commented 5 years ago

@N1ghtly If you have the ability to do so, it might be worth trying to upgrade to 0.60.4 and turn Hermes on. See @Kudo's comment here:

https://github.com/facebook/react-native/issues/24261#issuecomment-514288959

dhess-zynga commented 5 years ago

We're also seeing crashes on our build, w/ JSC r245459... @Kudo i attempted to symbolicate using your instructions from https://github.com/facebook/react-native/issues/25494#issuecomment-508460899, and here's what I came up with:

********** Crash dump: **********
pid: 0, tid: 0 >>> APPNAME <<<
Stack frame #00  pc 00000000000f7748  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const at sfp-exceptions.c:?
Stack frame #01  pc 0000000000143fe8  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const at sfp-exceptions.c:?
Stack frame #02  pc 000000000012f0a8  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&) at sfp-exceptions.c:?
Stack frame #03  pc 0000000000139484  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine JSC::ExecutableToCodeBlockEdge::runConstraint(JSC::ConcurrentJSLocker const&, JSC::VM&, JSC::SlotVisitor&) at sfp-exceptions.c:?
Stack frame #04  pc 000000000013900c  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&) at sfp-exceptions.c:?
Stack frame #05  pc 00000000001fb9c4  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine JSC::SlotVisitor::drain(WTF::MonotonicTime)::$_3::operator()(JSC::MarkStackArray&) const at sfp-exceptions.c:?
Stack frame #06  pc 00000000001f8e90  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine JSC::SlotVisitor::drain(WTF::MonotonicTime) at sfp-exceptions.c:?
Stack frame #07  pc 00000000001f96bc  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime) at sfp-exceptions.c:?
Stack frame #08  pc 00000000001e41a0  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine WTF::SharedTaskFunctor<void (), JSC::Heap::runBeginPhase(JSC::GCConductor)::$_17>::run() at sfp-exceptions.c:?
Stack frame #09  pc 00000000006171ec  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::SharedTask<void ()> > > const&) at sfp-exceptions.c:?
Stack frame #10  pc 0000000000617950  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine WTF::ParallelHelperPool::Thread::work() at sfp-exceptions.c:?
Stack frame #11  pc 000000000060de7c  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine WTF::Function<void ()>::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0>::call() at sfp-exceptions.c:?
Stack frame #12  pc 000000000061b084  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) at sfp-exceptions.c:?
Stack frame #13  pc 0000000000646dc8  /data/app/APPNAME-7N8FNwyuRgPc5XMrSr_hjQ==/lib/arm64/libjsc.so: Routine WTF::wtfThreadEntryPoint(void*) at sfp-exceptions.c:?
Stack frame #14  pc 0000000000069974  /system/lib64/libc.so (__pthread_start(void*)+36)
Stack frame #15  pc 000000000001f864  /system/lib64/libc.so (__start_thread+68)
mcuelenaere commented 5 years ago

We can confirm that the same issue occurs on beyondx (Samsung Galaxy S10 5G) on Android 9, which has an Exynos 9820 (ARMv8.2):

backtrace:
  #00  pc 00000000000f7748  /data/app/{APP_NAME}/lib/arm64/libjsc.so (JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const+16)
  #01  pc 0000000000143fe8  /data/app/{APP_NAME}/lib/arm64/libjsc.so (JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const+48)
  #02  pc 000000000012f0a8  /data/app/{APP_NAME}/lib/arm64/libjsc.so (JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&)+556)
  #03  pc 0000000000139484  /data/app/{APP_NAME}/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::runConstraint(JSC::ConcurrentJSLocker const&, JSC::VM&, JSC::SlotVisitor&)+40)
  #04  pc 000000000013900c  /data/app/{APP_NAME}/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)+1044)
  #05  pc 00000000001fb9c4  /data/app/{APP_NAME}/lib/arm64/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+324)
  #06  pc 00000000001f8e90  /data/app/{APP_NAME}/lib/arm64/libjsc.so (JSC::SlotVisitor::drain(WTF::MonotonicTime)+132)
  #07  pc 00000000001f96bc  /data/app/{APP_NAME}/lib/arm64/libjsc.so (JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)+580)
  #08  pc 00000000001e41a0  /data/app/{APP_NAME}/lib/arm64/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_17E3runEv+580)
  #09  pc 00000000006171ec  /data/app/{APP_NAME}/lib/arm64/libjsc.so (WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::DumbPtrTraits>> const&)+40)
  #10  pc 0000000000617950  /data/app/{APP_NAME}/lib/arm64/libjsc.so (WTF::ParallelHelperPool::Thread::work()+16)
  #11  pc 000000000060de7c  /data/app/{APP_NAME}/lib/arm64/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+376)
  #12  pc 000000000061b084  /data/app/{APP_NAME}/lib/arm64/libjsc.so (WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+212)
  #13  pc 0000000000646dc8  /data/app/{APP_NAME}/lib/arm64/libjsc.so (WTF::wtfThreadEntryPoint(void*)+4)
  #14  pc 0000000000084148  /system/lib64/libc.so (__pthread_start(void*)+64)
  #15  pc 0000000000023b28  /system/lib64/libc.so (__start_thread+68)
Kudo commented 5 years ago

Thank you all and especially @dhess-zynga providing symbolicated backtrace. It looks like the crash point are mostly the same. However, I am afraid that I am not able to help with this case if there's no reproduced steps. The crash seems happened at JSC bytecode being GCed during access. Without the JS source code & reproduce steps, it is hard to troubleshoot such problem for me. Maybe it is the time to try upgrading RN 0.60.4 and use Hermes engine. Or if you need a JSC disabled JIT (based on WebKitGTK 2.24), please feel free to let me know.

mars-lan commented 5 years ago

@Kudo Please publish a JIT disabled JSC for us to try out. Unfortunately Hermes isn't an option for some of us yet until intl support is added: https://github.com/facebook/hermes/issues/23

oliverdolgener commented 5 years ago

I can confirm crashes on a Huawei Mate 20 Pro running RN 0.59.10:

2019-07-30 10:36:37.063 14725-14944/{APP_NAME} A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x20 in tid 14944 (RenderThread), pid 14725 ({APP_NAME})
2019-07-30 10:36:37.146 15316-15316/? I/crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
2019-07-30 10:36:37.147 806-806/? I//system/bin/tombstoned: received crash request for pid 14944
2019-07-30 10:36:37.150 15316-15316/? I/crash_dump64: performing dump of process 14725 (target tid = 14944)
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG: Build fingerprint: 'HUAWEI/LYA-L29/HWLYA:9/HUAWEILYA-L29/146C432R1:user/release-keys'
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG: Revision: '0'
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG: ABI: 'arm64'
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG: pid: 14725, tid: 14944, name: RenderThread  >>> {APP_NAME} <<<
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x20
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG: Cause: null pointer dereference
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG:     x0  0000000000000000  x1  0000007cfed3730c  x2  0000000000000002  x3  0000007c585946f8
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG:     x4  0000000000000070  x5  0000007c58593104  x6  0000007c58593100  x7  0000007c585930fc
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG:     x8  0000000000000000  x9  0000000000000000  x10 0000000000000000  x11 0000000000000000
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG:     x12 ffffffffffe949dc  x13 0000007c5859c588  x14 0000000000000000  x15 0000000000000000
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG:     x16 0000007cff066118  x17 0000007cfee07d08  x18 0000000000000000  x19 0000000000000000
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG:     x20 0000000000000000  x21 0000007c1717e000  x22 0000000000000000  x23 0000000000000000
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG:     x24 0000000000000000  x25 0000007c5859c588  x26 0000000000000000  x27 0000000000000000
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG:     x28 0000000000000000  x29 0000007c585946c0
2019-07-30 10:36:37.159 15316-15316/? A/DEBUG:     sp  0000007c585946b0  lr  0000007cfe9be4b8  pc  0000007cfee07d18
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG: backtrace:
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #00 pc 000000000053ed18  /system/lib64/libhwui.so (SkSurface::getCanvas()+16)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #01 pc 00000000000f54b4  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::GLFunctorDrawable::onDraw(SkCanvas*)+1204)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #02 pc 000000000045a8b4  /system/lib64/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+352)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #03 pc 000000000045afc8  /system/lib64/libhwui.so (SkLiteDL::draw(SkCanvas*) const+204)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #04 pc 000000000043e8e0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+292)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #05 pc 000000000043eca0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+252)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #06 pc 000000000045a7e8  /system/lib64/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+148)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #07 pc 000000000045afc8  /system/lib64/libhwui.so (SkLiteDL::draw(SkCanvas*) const+204)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #08 pc 000000000043e8e0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+292)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #09 pc 000000000043eca0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+252)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #10 pc 000000000045a7e8  /system/lib64/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+148)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #11 pc 000000000045afc8  /system/lib64/libhwui.so (SkLiteDL::draw(SkCanvas*) const+204)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #12 pc 000000000043e8e0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+292)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #13 pc 000000000043eca0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+252)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #14 pc 000000000045a7e8  /system/lib64/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+148)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #15 pc 000000000045afc8  /system/lib64/libhwui.so (SkLiteDL::draw(SkCanvas*) const+204)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #16 pc 000000000043e8e0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+292)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #17 pc 000000000043eca0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+252)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #18 pc 000000000045a7e8  /system/lib64/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+148)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #19 pc 000000000045afc8  /system/lib64/libhwui.so (SkLiteDL::draw(SkCanvas*) const+204)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #20 pc 000000000043e8e0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+292)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #21 pc 000000000043eca0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+252)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #22 pc 000000000045a7e8  /system/lib64/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+148)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #23 pc 000000000045afc8  /system/lib64/libhwui.so (SkLiteDL::draw(SkCanvas*) const+204)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #24 pc 000000000043e8e0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+292)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #25 pc 000000000043eca0  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+252)
2019-07-30 10:36:37.192 15316-15316/? A/DEBUG:     #26 pc 00000000000fdc3c  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaPipeline::renderLayersImpl(android::uirenderer::LayerUpdateQueue const&, bool, bool)+784)
2019-07-30 10:36:37.193 15316-15316/? A/DEBUG:     #27 pc 000000000047f848  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaPipeline::renderFrame(android::uirenderer::LayerUpdateQueue const&, SkRect const&, std::__1::vector<android::sp<android::uirenderer::RenderNode>, std::__1::allocator<android::sp<android::uirenderer::RenderNode>>> const&, bool, bool, android::uirenderer::Rect const&, sk_sp<SkSurface>)+96)
2019-07-30 10:36:37.193 15316-15316/? A/DEBUG:     #28 pc 000000000047e270  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::draw(android::uirenderer::renderthread::Frame const&, SkRect const&, SkRect const&, android::uirenderer::FrameBuilder::LightGeometry const&, android::uirenderer::LayerUpdateQueue*, android::uirenderer::Rect const&, bool, bool, android::uirenderer::BakedOpRenderer::LightInfo const&, std::__1::vector<android::sp<android::uirenderer::RenderNode>, std::__1::allocator<android::sp<android::uirenderer::Re
2019-07-30 10:36:37.193 15316-15316/? A/DEBUG:     #29 pc 0000000000108ffc  /system/lib64/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+240)
2019-07-30 10:36:37.193 15316-15316/? A/DEBUG:     #30 pc 00000000004838d0  /system/lib64/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+644)
2019-07-30 10:36:37.193 15316-15316/? A/DEBUG:     #31 pc 000000000043d828  /system/lib64/libhwui.so (android::uirenderer::WorkQueue::process()+168)
2019-07-30 10:36:37.193 15316-15316/? A/DEBUG:     #32 pc 00000000001167a8  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+240)
2019-07-30 10:36:37.193 15316-15316/? A/DEBUG:     #33 pc 000000000000fa44  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+280)
2019-07-30 10:36:37.193 15316-15316/? A/DEBUG:     #34 pc 0000000000082dfc  /system/lib64/libc.so (__pthread_start(void*)+36)
2019-07-30 10:36:37.193 15316-15316/? A/DEBUG:     #35 pc 0000000000024080  /system/lib64/libc.so (__start_thread+68)
smoczynskicitiz commented 5 years ago

Hello !

I just updated my application on the PlayStore today, I use now the RN version 0.59.10, and I have this problem on a device. I saw this on the Google Play Console.

The device is Galaxy S8+ (dream2lte) on Android 9.

backtrace:
  #00  pc 00000000000f7748  /data/data/{package_name}/lib-0/libjsc.so (JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const+16)
  #01  pc 0000000000143fe8  /data/data/{package_name}/lib-0/libjsc.so (JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const+48)
  #02  pc 000000000012f0a8  /data/data/{package_name}/lib-0/libjsc.so (JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&)+556)
  #03  pc 0000000000139484  /data/data/{package_name}/lib-0/libjsc.so (JSC::ExecutableToCodeBlockEdge::runConstraint(JSC::ConcurrentJSLocker const&, JSC::VM&, JSC::SlotVisitor&)+40)
  #04  pc 000000000013900c  /data/data/{package_name}/lib-0/libjsc.so (JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)+1044)
  #05  pc 00000000001fb9c4  /data/data/{package_name}/lib-0/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+324)
  #06  pc 00000000001f8e90  /data/data/{package_name}/lib-0/libjsc.so (JSC::SlotVisitor::drain(WTF::MonotonicTime)+132)
  #07  pc 00000000001f96bc  /data/data/{package_name}/lib-0/libjsc.so (JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)+580)
  #08  pc 00000000001e41a0  /data/data/{package_name}/lib-0/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_17E3runEv+580)
  #09  pc 00000000006171ec  /data/data/{package_name}/lib-0/libjsc.so (WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::DumbPtrTraits>> const&)+40)
  #10  pc 0000000000617950  /data/data/{package_name}/lib-0/libjsc.so (WTF::ParallelHelperPool::Thread::work()+16)
  #11  pc 000000000060de7c  /data/data/{package_name}/lib-0/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+376)
  #12  pc 000000000061b084  /data/data/{package_name}/lib-0/libjsc.so (WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+212)
  #13  pc 0000000000646dc8  /data/data/{package_name}/lib-0/libjsc.so (WTF::wtfThreadEntryPoint(void*)+4)
  #14  pc 0000000000084dc0  /system/lib64/libc.so (__pthread_start(void*)+208)
  #15  pc 0000000000023a4c  /system/lib64/libc.so (__start_thread+68)
janczizikow commented 5 years ago

I've also saw similar crashes on multiple devices in Google Play Store crash report. Unfortunately I cannot easily upgrade to 0.60+ and try out Hermes. Anyone tried upgrading and trying out Hermes yet?

RN: 0.59.10 Android 9 Devices:

backtrace:

  #00  pc 00000000000f7748  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const+16)
  #01  pc 0000000000143fe8  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const+48)
  #02  pc 000000000012f0a8  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&)+556)
  #03  pc 0000000000139484  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::runConstraint(JSC::ConcurrentJSLocker const&, JSC::VM&, JSC::SlotVisitor&)+40)
  #04  pc 000000000013900c  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)+1044)
  #05  pc 00000000001fb9c4  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+324)
  #06  pc 00000000001f8e90  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (JSC::SlotVisitor::drain(WTF::MonotonicTime)+132)
  #07  pc 00000000001f96bc  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)+580)
  #08  pc 00000000001e41a0  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_17E3runEv+580)
  #09  pc 00000000006171ec  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::DumbPtrTraits>> const&)+40)
  #10  pc 0000000000617950  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (WTF::ParallelHelperPool::Thread::work()+16)
  #11  pc 000000000060de7c  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+376)
  #12  pc 000000000061b084  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+212)
  #13  pc 0000000000646dc8  /data/app/{package_name}-1_OKn7xVjBSXDhWrN582vQ==/lib/arm64/libjsc.so (WTF::wtfThreadEntryPoint(void*)+4)
  #14  pc 0000000000083530  /system/lib64/libc.so (__pthread_start(void*)+36)
  #15  pc 00000000000241dc  /system/lib64/libc.so (__start_thread+68)
j-wang commented 5 years ago

We see it intermittently as well... Unfortunately, Hermes doesn't yet support some things that are relatively common in our codebase (and I think that of a lot of folks), specifically (Actually I just realized it's probably babel'ed in—we'll probably try it on our side and report back):

https://github.com/facebook/hermes/blob/master/doc/Features.md

Despite heroic efforts to track it down/fix it from @Kudo and folks, it might be worth going backward vs. forward to before 0.59, when the JSC was upgraded. We like trying to stay updated on features, but crashes/freezing/etc. on production apps that we can't stop are making us consider waiting until 0.60+/Hermes is more mature to actually have hooks, etc. that came with 0.59+.

oliverdolgener commented 5 years ago

Hey guys, I've found what caused the problem in our app. we are using react-navigation in combination with useScreens. There seems to be a problem in the useScreens code:

https://github.com/kmagiera/react-native-screens/issues/105

deactivating and removing useScreens seems to fix the crashes

mars-lan commented 5 years ago

Can confirm that I too use react-navigation but not using useScreens.

smoczynskicitiz commented 5 years ago

Hey,

Same as @mars-lan , using react-navigation 3.0.0 but not useScreens.

j-wang commented 5 years ago

We also use react-navigation (3.7.1) as well—but similar to the other folks here, don't use useScreens. One of our early theories was something with navigation (since it seemed to happen more often when we interacted with navigation elements). We had cleared it later after seeing other reports that seemed to say they didn't have it, but will test on our side and see if it resolves it.

thomasonweb commented 5 years ago

We have released React Native 0.60.4 on Wednesday using Hermes on Android and I can confirm there are no more 64-bit crashes (at least not yet at this point). In fact, Hermes improved our average app boot time from 5.8s to 2.5s or even less on higher end devices.

One thing to note: If you support Android 4 you should use the latest version of "hermes-engine" (0.1.1) as the current "hermesvm" (0.1.0) integration in React Native 0.60.4 makes the app crash on boot time. See https://github.com/facebook/hermes/issues/42 for more info on that.

blohamen commented 5 years ago

Hi all. ~~I updated app to RN 0.60.4 but crashes still have. I tested on real devices, but i can't give backtrace :( Devices with crash:~~ htc u11 plus 8.0 Huawei nexus 6p 8.1 Motorola moto g6 8.0 LGE Nexus 5X Android 8.0.0 samsung galaxy S8 8 0 samsung galaxy S8 PLUS 8 0 samsung galaxy S9 8 0 samsung galaxy S9 Plus 8 0 sony Xperia xa 1 80 Sony Xperia XZ2 Android 8.0.0 I must say right away that it’s impossible to turn on Hermes because Realm Db cannot work with it yet

Updated:

Well, it is my fail. This is a crash not because of JSC but because of a problem with portrait mode in SDK 26 (android 8)

john1jan commented 5 years ago

Same crash hapening for me as well

F/libc (14838): Fatal signal 11 (SIGSEGV) in tid 14959 (mqt_js) F/libc (14838): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xa6cca6cc510534

loginov-rocks commented 5 years ago

Hey guys, this appears to be absolute blocker for all Android apps using React Native to be updated since Google Play not allow to push apps without 64 bit support from Aug 1.

And we can't go back to previous RN versions since they don't support 64 bit at all. Am I missing something? Please correct.

It's not clear if anybody from React Native team aware of that. Is there any way to escalate this issue?

mars-lan commented 5 years ago

We're indeed being blocked by this issue. @j-wang any luck with the debugging?

tanx commented 5 years ago

Hey guys, this appears to be absolute blocker for all Android apps using React Native to be updated since Google Play not allow to push apps without 64 bit support from Aug 1.

We're blocked as well since expo unimodules don't support 0.60.x. We're currently only able to push updates to iOS users, but not Android :/

j-wang commented 5 years ago

@mars-lan Unfortunately, playing around with an app with react-navigation entirely stripped out still seems to cause the issue... It's kind of tricky to pin down since the amount of time that has to go by before JSC crashes is pretty variable. Maybe it takes a bit longer without react-navigation...? But it still crashes.

NathanielWaggoner commented 5 years ago

I can confirm that this most recent JSC does not resolve all crashes. We still see a large number of them on a variety of devices in google play. We've upgraded anyway since it's required for google play, but it's upped our crash rate almost 2%. Huge issue and needs attention ASAP.

We do not use React-Navigation, nor do we support android 4.

NathanielWaggoner commented 5 years ago

@j-wang did you try turning hermes on? did it help? We're considering trying that but are very skeptical at this point that it will do anything.

j-wang commented 5 years ago

@NathanielWaggoner I had put it off/left it for now since we hit some blockers with international support (https://github.com/facebook/hermes/issues/23). We don't technically support non-English stuff yet, but certain libraries with datetime, currency, etc all need it and unexpectedly are affected.

The Hermes team currently, as per the issue, has no plans on adding it. As such... we could test more, but even if we rip out all of our utility functions and replace them, we'll also be expanding to other languages/locales soon, which makes it kind of moot as a solution if it does work.

... Which does actually does mean we're seriously considering un-hookifying some of our code and just rolling back to before 0.59.

loginov-rocks commented 5 years ago

@j-wang as far as I understand if rolling back to the version before 0.59 you'll not be able to support 64 bit.

To add about Hermes, for example in our project we don't have app/build.gradle to configure enableHermes - we configure options in the code, using builder class if I remember correctly, but at the moment framework doesn't provide such option for enabling Hermes. And I don't think it's time to use newborn technology.

re7eal commented 5 years ago

https://github.com/Kudo/react-native-v8 seems to be an interesting alternative. I haven't tried it out though.

j-wang commented 5 years ago

@loginov-rocks Ah, true that is... Well, I guess that saves us some re-work work. We had originally upgraded for hooks and hadn't even realized that the 64-bit option only came with RN-0.59.

Unfortunately, I guess there are no real options then. Another plan was just to try and see if we could kludge together the old JSC + the new RN, but I guess it looks like the JSC is what allows 64-bit to begin with. I suppose the last thing to try and see if we can somehow polyfill Intl for Hermes not having it?

We've already frozen our Android app, but it's pretty much stranded without the ability to upgrade anymore on the Google Play Store.

Kudo commented 5 years ago

Hopefully if you could provide reproduced JS code and steps. Otherwise that is really difficult to find the root cause.

IMO, react-native-v8 might be a good option as that V8 on Android is reliable than JSC on Android. At least Chrome on Android should be the most heavy user to use V8. react-native-v8 did support 0.59.10 now and Intl is by default on. Please take a look and feel free to let me know if you faced any problems.

@j-wang old JSC + new RN is also possible, there is jsc-android@174650.0.2. However, the arm64 version is not well tested and we are not sure if it is stable or not. Intl polyfill + Hermes is also a good option from my point of view. I was thinking that we should leverage system's L10n to support Intl instead of ICU data that cost about 7MB binary size in JS engine.

YoranRoels commented 5 years ago

We are using React-Native 0.60.5 + Hermes + 64-bit enabled and we are experiencing this error on HUAWEI MYA-L41, so Hermes alone doesn't fix it. Turning off 64-bit seems to avoid these issues, which is obviously not a solution since it's now mandatory to have 64-bit support when releasing an app. Has anybody made any progress regarding this issue or is it a different issue for each device? If I can provide any extra info, let me know.

kylethielk commented 5 years ago

@YoranRoels We have a small sample size of affected devices so take this with a grain of salt. We received a lot of complaints from a few users about 5+ crashes a day on 0.59.10.

We created Beta release of 0.60.4 + Hermes and it fixed the crashes for these effected users. As far as I'm aware these were all specific Samsung devices. It seems like these are very device specific issues.

YoranRoels commented 5 years ago

@kylethielk Thanks for the swift response and the input.

I'm glad it has fixed it for your specific Samsung devices but at the moment we're afraid to roll out an app update since we don't have a large enough beta subset to be sure that it's fixed for all devices (it's already a 100% certainty that it doesn't work on the Huawei device that we test since we've tried multiple release builds on that device).

smacgregor commented 5 years ago

@YoranRoels - if your JS runtime is Hermes it shouldn't be possible to get this crash inside libjsc. Hermes replaces JSC on Android. Might want to double check that your app is really using Hermes if you are seeing stack traces with libjsc on these devices. Cheers.

Rebsos commented 5 years ago

I recently rolled out RN 0.59.10 to an app I manage with ~80k users and saw the same crashes like mentioned above. There is nothing devices specific visible. Most are Samsung and Huawei, so are the crashes. Look at the last column, for sure we can say: The higher the android version, the more likely there will be a crash. This are the crashes just from yesterday:

. Crashes Devices % Crashes per Devices %
All 127 100% 0,17%
Android 9 75 26,87% 0,36%
Android 8.0 35 20,05% 0,23%
Android 7.0 10 12,04% 0,11%
Android 6.0 4 11,69% 0,04%
Android 8.1 1 8,42% 0,02%
Android 5.1 1 5,72% 0,02%
Android 4.4 0 5,40% 0,00%
Android 7.1 1 4,36% 0,03%
Android 5.0 0 2,96% 0,00%
Android 4.2 0 1,08% 0,00%
Android 4.3 0 0,69% 0,00%
Android 4.1 0 0,69% 0,00%

0,36% of Android 9 devices crashed yesterday

The crashes are very random. We can't reproduce them. This is also visible in the statics. 127 Crashes on 120 users.

john1jan commented 5 years ago

We are also facing the same situation, after the RN update to 0.59, our crash rates are increasing. What is the solution for this ?

john1jan commented 5 years ago

https://github.com/facebook/react-native/issues/25782

sunnylqm commented 5 years ago

@john1jan Read all the comments above. Try 0.59.10 first, then try hermes or v8.

j-wang commented 5 years ago

On our side, tentatively hopeful for RN 0.60.5 + Hermes. It appears to be working without crashes—in all other cases, we've generally been able to replicate crashes on one of our fairly large collections of Android test phones.

So far, we haven't gotten anything. We'll probably be putting together a production release soon, so we'll see what happens out in the wild.

tanx commented 5 years ago

I hope this helps others that are still on 0.59.10. But using https://github.com/Kudo/react-native-v8 solved the issue for us. See also: https://github.com/facebook/react-native/issues/24261#issuecomment-525404545

YoranRoels commented 5 years ago

@smacgregor I came at this issue all wrong and it has nothing to do with this indeed, this was not our main error anymore since switching to Hermes, apologies. I still had this issue open when debugging several things at a time and I posted on several issues, this now being off-topic. We are now on 0.60.5 + Hermes and can confirm that's it's stable so far on all our test devices. Thanks for getting back to me either way!

Rebsos commented 5 years ago

@tanx on how many users did you test 0.59.10+V8?

lecramfriedrich commented 5 years ago

On our side, tentatively hopeful for RN 0.60.5 + Hermes. It appears to be working without crashes—in all other cases, we've generally been able to replicate crashes on one of our fairly large collections of Android test phones.

So far, we haven't gotten anything. We'll probably be putting together a production release soon, so we'll see what happens out in the wild.

@j-wang Please Let us know if this worked "in the wild". @tanx Good news that v8 solved it for you. 👍

xanderdeseyn commented 5 years ago

We are currently trying out V8 as well. Looks promising, no crashes yet. Will soon roll out to 300K+ devices and report back!

j-wang commented 5 years ago

@lecramfriedrich Rolled out in production to everyone since yesterday, no crashes yet—so far so good.

taschik commented 5 years ago

@j-wang on RN0.60 or 0.59?