Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ebaynaud opened this issue Jul 4, 2019 · 73 comments

Comments

@ebaynaud
Copy link

@ebaynaud ebaynaud commented Jul 4, 2019

Same as #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)
@ebaynaud ebaynaud added the Bug label Jul 4, 2019
@ebaynaud ebaynaud changed the title signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) libjsc.so still occuring on Caterpillar S41 signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) libjsc.so still occuring on Caterpillar S41 (Android 8.0) Jul 4, 2019
@Kudo

This comment has been minimized.

Copy link
Contributor

@Kudo Kudo commented Jul 4, 2019

@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

This comment has been minimized.

Copy link
Author

@ebaynaud ebaynaud commented Jul 4, 2019

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

This comment has been minimized.

Copy link

@thomasonweb thomasonweb commented Jul 9, 2019

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)
@N1ghtly

This comment has been minimized.

Copy link

@N1ghtly N1ghtly commented Jul 15, 2019

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

@jsaraiva

This comment has been minimized.

Copy link

@jsaraiva jsaraiva commented Jul 20, 2019

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

This comment has been minimized.

Copy link

@mars-lan mars-lan commented Jul 20, 2019

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)
@N1ghtly

This comment has been minimized.

Copy link

@N1ghtly N1ghtly commented Jul 23, 2019

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

@j-wang

This comment has been minimized.

Copy link

@j-wang j-wang commented Jul 23, 2019

@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:

#24261 (comment)

@dhess-zynga

This comment has been minimized.

Copy link

@dhess-zynga dhess-zynga commented Jul 24, 2019

We're also seeing crashes on our build, w/ JSC r245459... @Kudo i attempted to symbolicate using your instructions from #25494 (comment), 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

This comment has been minimized.

Copy link
Contributor

@mcuelenaere mcuelenaere commented Jul 25, 2019

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

This comment has been minimized.

Copy link
Contributor

@Kudo Kudo commented Jul 25, 2019

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

This comment has been minimized.

Copy link

@mars-lan mars-lan commented Jul 25, 2019

@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: facebook/hermes#23

@oliverdolgener

This comment has been minimized.

Copy link

@oliverdolgener oliverdolgener commented Jul 30, 2019

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

This comment has been minimized.

Copy link

@smoczynskicitiz smoczynskicitiz commented Jul 30, 2019

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

This comment has been minimized.

Copy link

@janczizikow janczizikow commented Jul 30, 2019

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:

  • Pixel 3 (blueline)
  • Nokia 7 plus (B2N_sprout)
  • Galaxy S9 (starlte)
  • Pixel 2 (walleye)
  • Pixel 3 XL (crosshatch)
  • Galaxy S10+ (beyond2)

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

This comment has been minimized.

Copy link

@j-wang j-wang commented Jul 30, 2019

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

  • let and const (block scoped variables, with support for the temporal dead zone)
  • Classes and method definitions
  • Computed property keys on object literals
  • ES modules (import and export)

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

This comment has been minimized.

Copy link

@oliverdolgener oliverdolgener commented Jul 31, 2019

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:

kmagiera/react-native-screens#105

deactivating and removing useScreens seems to fix the crashes

@mars-lan

This comment has been minimized.

Copy link

@mars-lan mars-lan commented Jul 31, 2019

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

@smoczynskicitiz

This comment has been minimized.

Copy link

@smoczynskicitiz smoczynskicitiz commented Jul 31, 2019

Hey,

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

@j-wang

This comment has been minimized.

Copy link

@j-wang j-wang commented Jul 31, 2019

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

This comment has been minimized.

Copy link

@thomasonweb thomasonweb commented Aug 2, 2019

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 facebook/hermes#42 for more info on that.

@blohamen

This comment has been minimized.

Copy link

@blohamen blohamen commented Aug 7, 2019

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

This comment has been minimized.

Copy link

@john1jan john1jan commented Aug 9, 2019

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

This comment has been minimized.

Copy link

@loginov-rocks loginov-rocks commented Aug 9, 2019

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?

@lecramfriedrich

This comment has been minimized.

Copy link

@lecramfriedrich lecramfriedrich commented Aug 28, 2019

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. 👍

@N1ghtly

This comment has been minimized.

Copy link

@N1ghtly N1ghtly commented Aug 29, 2019

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

This comment has been minimized.

Copy link

@j-wang j-wang commented Aug 30, 2019

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

@taschik

This comment has been minimized.

Copy link

@taschik taschik commented Aug 30, 2019

@j-wang on RN0.60 or 0.59?

@j-wang

This comment has been minimized.

Copy link

@j-wang j-wang commented Aug 30, 2019

@taschik 0.60.5 with Hermes.

0.59.10 doesn't fix it, and 0.60.5 without JSC swapped out for Hermes (or v8, though I personally haven't tried it) doesn't fix it.

@oximer

This comment has been minimized.

Copy link

@oximer oximer commented Sep 9, 2019

@N1ghtly are you using 0.59 with v8?

@mars-lan

This comment has been minimized.

Copy link

@mars-lan mars-lan commented Sep 9, 2019

Glad to report that we've fully rolled out with 0.60.5 + v8 and it worked extremely well. Seeing far fewer crashes than JSC.

@rawrmaan

This comment has been minimized.

Copy link
Contributor

@rawrmaan rawrmaan commented Sep 9, 2019

I've also rolled out 0.59.8 + V8 in production and can confirm that it reduced JS engine originated crashes by 80-90%, not to mention drastically improving performance in some key parts of my app.

@douglasjunior

This comment has been minimized.

Copy link

@douglasjunior douglasjunior commented Sep 9, 2019

@mars-lan @rawrmaan how about the APK final size with v8?

@rawrmaan

This comment has been minimized.

Copy link
Contributor

@rawrmaan rawrmaan commented Sep 9, 2019

@douglasjunior APK size was increased by 4.2MB

@oximer

This comment has been minimized.

Copy link

@oximer oximer commented Sep 9, 2019

Since there are many people suffering with this problem.
Let me report my app situation.

First, we migrate our app to React 0.59.8.
This cause use more than 3% of Application Not Responding and Crashes.
I was not able to see those crashes through Crashlytics. I saw it through google play store.
We have more than 16 Million users and it mainly affects Samsungs and Xiaomi such as Galaxy S7. The app crash on the first screen for those user.

Then, we migrate our app for React 0.59.10
This reduce our ANR and random crashes for less than 1%.
However, I have more than 30k users impacted by this bug.
Google play still the best place to see these problem. Many crashes occurs on the first milliseconds, so Crashlytics don't catch them.

We can't migrate our app to Hemes + React Native 0.61
We use many libraries that are not compatible with Android X.
Thus, we decide to give V8 an try.

I removed JSC, adding V8. I use @Kudo repo to it.
It took me last them half hour to do it, but I not sure if it will cause me some side effects.
The QA team is validating this new app version.
We expect to go on a full rollout on the next weeks.

Since Hermes seems the best engine, we should use it as soon as we are able to migrate our app to Android X.

@Kudo

This comment has been minimized.

Copy link
Contributor

@Kudo Kudo commented Sep 10, 2019

react-native-v8 did support RN 0.59.10, this provides an option if someone not able upgrade 0.60 to try Hermes.
The APK size for V8 increased a lot due to Intl support by default.
I will work on a non-Intl version hopefully to decrease the APK size a little bit.
However, V8's size is still larger than JSC and Hermes even for non-Intl due to other features. (E.g. V8 has not option to disable WebAssembly)

@N1ghtly

This comment has been minimized.

Copy link

@N1ghtly N1ghtly commented Sep 10, 2019

@N1ghtly are you using 0.59 with v8?

We are using 0.60.4. Rollout is scheduled for tomorrow.

@Kudo

This comment has been minimized.

Copy link
Contributor

@Kudo Kudo commented Sep 11, 2019

react-native-v8 no Intl version available, in case if you want to reduce APK size and didn't use Intl.
https://github.com/Kudo/react-native-v8/blob/master/README.md#how-to-reduce-apk-size-

@t0m0120

This comment has been minimized.

Copy link

@t0m0120 t0m0120 commented Sep 12, 2019

we are using 0.59.10
No longer crashes when changing from jsc to v8

@N1ghtly

This comment has been minimized.

Copy link

@N1ghtly N1ghtly commented Sep 18, 2019

Can confirm that V8 fixed the issue for us.

@YMIUA

This comment has been minimized.

Copy link

@YMIUA YMIUA commented Oct 1, 2019

Hello, everyone. I had error
A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0xca35ca354bda7a in tid 23013 (mqt_js) A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x7f5e600000 in tid 23049 (FrescoDecodeExe)
with EXPO 34.0.4 in few mobile phone. I fix this error after seting defoult uri for all my image component.

@rouge3351

This comment has been minimized.

Copy link

@rouge3351 rouge3351 commented Oct 20, 2019

same on RN 0.61.0 / jsc-android : 245459.0.0


pid: 0, tid: 0 >>> applicationID <<<

backtrace:
#00 pc 00000000000f7748 /data/data/applicationID/lib-0/libjsc.so
#1 pc 0000000000143fe8 /data/data/applicationID/lib-0/libjsc.so
#2 pc 000000000012f0a8 /data/data/applicationID/lib-0/libjsc.so
#3 pc 0000000000139484 /data/data/applicationID/lib-0/libjsc.so
#4 pc 000000000013900c /data/data/applicationID/lib-0/libjsc.so
#5 pc 00000000001fb9c4 /data/data/applicationID/lib-0/libjsc.so
#6 pc 00000000001f8e90 /data/data/applicationID/lib-0/libjsc.so
#7 pc 00000000001f96bc /data/data/applicationID/lib-0/libjsc.so
#8 pc 00000000001e41a0 /data/data/applicationID/lib-0/libjsc.so
#9 pc 00000000006171ec /data/data/applicationID/lib-0/libjsc.so
#10 pc 0000000000617950 /data/data/applicationID/lib-0/libjsc.so
#11 pc 000000000060de7c /data/data/applicationID/lib-0/libjsc.so
#12 pc 000000000061b084 /data/data/applicationID/lib-0/libjsc.so
#13 pc 0000000000646dc8 /data/data/applicationID/lib-0/libjsc.so
#14 pc 0000000000084dc0 /system/lib64/libc.so (__pthread_start(void*)+208)
#15 pc 0000000000023a4c /system/lib64/libc.so (__start_thread+68)

@pratikpatel39

This comment has been minimized.

Copy link

@pratikpatel39 pratikpatel39 commented Nov 4, 2019

I have buit JSC: r250230 from https://github.com/Kudo/jsc-android-buildscripts/tree/jsc_2_26_1 and applied this patch https://trac.webkit.org/changeset/251307/webkit and run ~3500 times and I don't see this JSC crash anymore, I would encounter this crash once or twice if I use JSC r245459 and run it ~1000 times.
We will roll this out and see if it actually fixes the issue.
Thanks @Kudo and Webkit team for your support!

@tobi512

This comment has been minimized.

Copy link

@tobi512 tobi512 commented Nov 14, 2019

Since we upgraded the JSC to r245459 our crashes were drastically reduced. However, we also still see some crashes (they look identical like the ones already posted above):

Huawei Mate 10 Pro (HWBLA), Android 9
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> appId <<<

backtrace:
  #00  pc 00000000000f7748  /data/data/appId/lib-main/libjsc.so
  #01  pc 0000000000143fe8  /data/data/appId/lib-main/libjsc.so
  #02  pc 000000000012f0a8  /data/data/appId/lib-main/libjsc.so
  #03  pc 0000000000139484  /data/data/appId/lib-main/libjsc.so
  #04  pc 000000000013900c  /data/data/appId/lib-main/libjsc.so
  #05  pc 00000000001fb9c4  /data/data/appId/lib-main/libjsc.so
  #06  pc 00000000001f8e90  /data/data/appId/lib-main/libjsc.so
  #07  pc 00000000001f96bc  /data/data/appId/lib-main/libjsc.so
  #08  pc 00000000001e41a0  /data/data/appId/lib-main/libjsc.so
  #09  pc 00000000006171ec  /data/data/appId/lib-main/libjsc.so
  #10  pc 0000000000617950  /data/data/appId/lib-main/libjsc.so
  #11  pc 000000000060de7c  /data/data/appId/lib-main/libjsc.so
  #12  pc 000000000061b084  /data/data/appId/lib-main/libjsc.so
  #13  pc 0000000000646dc8  /data/data/appId/lib-main/libjsc.so
  #14  pc 0000000000083588  /system/lib64/libc.so (__pthread_start(void*)+36)
  #15  pc 00000000000241dc  /system/lib64/libc.so (__start_thread+68)

We'll probably try the patched JSC version from @pratikpatel39 at some point, any plans if and when this will be merged so we get an official version of the JSC with the fix included?

@sunnylqm

This comment has been minimized.

Copy link
Contributor

@sunnylqm sunnylqm commented Nov 14, 2019

@tobi512 JSC is maintained by community so there will be no official version of JSC. Facebook is using hermes.
Current options if you somehow do not want to use hermes:

  1. Some mentioned that if image is given a null url might cause the crash in some devices. Can check that first.
  2. AFAIK, all version of jsc (including the latest patched one) have crash reports. Try react-native-v8 as there are No crash report yet.
@tobi512

This comment has been minimized.

Copy link

@tobi512 tobi512 commented Nov 14, 2019

Hi @sunnylqm,
thanks for your quick reply! Hermes (and probably v8 too, I'll check that) is currently no option for us since we use Sentry.io for crash reporting and they do not yet support Hermes. As soon as they do, we'll definitely upgrade to Hermes, just need to find a solution for the meantime...

@fbartho

This comment has been minimized.

Copy link
Contributor

@fbartho fbartho commented Nov 14, 2019

Unfortunately, Hermes is not an option for us until it supports Intl, and is a largeish lift for us if they don’t support Proxy. If/when they support Intl, I might try to spike a migration for us.

@schumannd

This comment has been minimized.

Copy link

@schumannd schumannd commented Nov 15, 2019

To everyone using Hermes or V8: What do you use for error reporting? Any good alternatives to sentry.io that can handle hermes or V8?

@ebaynaud

This comment has been minimized.

Copy link
Author

@ebaynaud ebaynaud commented Nov 15, 2019

@schumannd I'm using Bugsnag. I now that Hermès is supported but I'm still trying to migrate to RN 0.60 so not tested yet.

@smacgregor

This comment has been minimized.

Copy link

@smacgregor smacgregor commented Nov 15, 2019

@schumannd - we use Bugsnag + Hermes + typescript. Bugsnag & Hermes work well together for us in production.

@tobi512

This comment has been minimized.

Copy link

@tobi512 tobi512 commented Nov 15, 2019

Thanks @ebaynaud and @smacgregor that's good to know. We just integrated Sentry couple weeks ago, if we'd known that before, we probably would have chosen Bugsnag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.