react-native-screens: Native C++ crashes on Android 9 on React Native 0.59

Closing this since #607 is merged. Comment here please if the crash appears after that commit and applying workaround for native-stack.

Same crash on Android 9:

03-27 21:26:34.466 19636 19636 I crash_dump32: performing dump of process 19435 (target tid = 19494)
03-27 21:26:34.504 19636 19636 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-27 21:26:34.504 19636 19636 F DEBUG   : Build fingerprint: 'Xiaomi/olivelite/olivelite:9/PKQ1.190319.001/V11.0.7.0.PCPCNXM:user/release-keys'
03-27 21:26:34.505 19636 19636 F DEBUG   : Revision: '0'
03-27 21:26:34.505 19636 19636 F DEBUG   : ABI: 'arm'
03-27 21:26:34.505 19636 19636 F DEBUG   : pid: 19435, tid: 19494, name: RenderThread  >>> com.demlution.dwapp <<<
03-27 21:26:34.505 19636 19636 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1c
03-27 21:26:34.505 19636 19636 F DEBUG   : Cause: null pointer dereference
03-27 21:26:34.505 19636 19636 F DEBUG   :     r0  00000000  r1  9c4f3640  r2  aa2b6465  r3  00000000
03-27 21:26:34.505 19636 19636 F DEBUG   :     r4  00000000  r5  00000000  r6  61d097e0  r7  00000002
03-27 21:26:34.505 19636 19636 F DEBUG   :     r8  00000000  r9  00000300  r10 aa7f4028  r11 00000000
03-27 21:26:34.505 19636 19636 F DEBUG   :     ip  aa7f2618  sp  889f2f90  lr  aa411243  pc  aa5bfa34
03-27 21:26:34.591 19636 19636 F DEBUG   : 
03-27 21:26:34.591 19636 19636 F DEBUG   : backtrace:
03-27 21:26:34.591 19636 19636 F DEBUG   :     #00 pc 003d1a34  /system/lib/libhwui.so (SkSurface::getCanvas()+4)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #01 pc 0022323f  /system/lib/libhwui.so (android::uirenderer::skiapipeline::GLFunctorDrawable::onDraw(SkCanvas*)+1070)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #02 pc 0020612b  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+214)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #03 pc 00206a01  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+152)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #04 pc 001f49f1  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+1084)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #05 pc 0008744f  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+266)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #06 pc 002060b9  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #07 pc 00206a01  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+152)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #08 pc 001f49f1  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+1084)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #09 pc 0008744f  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+266)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #10 pc 002060b9  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #11 pc 00206a01  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+152)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #12 pc 001f49f1  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+1084)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #13 pc 0008744f  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+266)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #14 pc 002060b9  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #15 pc 00206a01  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+152)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #16 pc 001f49f1  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+1084)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #17 pc 0008744f  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+266)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #18 pc 002060b9  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #19 pc 00206a01  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+152)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #20 pc 001f49f1  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+1084)
03-27 21:26:34.591 19636 19636 F DEBUG   :     #21 pc 0008744f  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+266)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #22 pc 002060b9  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #23 pc 00206a01  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+152)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #24 pc 001f49f1  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+1084)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #25 pc 0008744f  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+266)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #26 pc 002060b9  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #27 pc 00206a01  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+152)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #28 pc 001f49f1  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+1084)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #29 pc 0008744f  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+266)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #30 pc 0022aa85  /system/lib/libhwui.so (android::uirenderer::skiapipeline::SkiaPipeline::renderLayersImpl(android::uirenderer::LayerUpdateQueue const&, bool, bool)+252)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #31 pc 0022b7db  /system/lib/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>)+42)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #32 pc 001f5363  /system/lib/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::RenderNode>>
03-27 21:26:34.592 19636 19636 F DEBUG   :     #33 pc 00231edd  /system/lib/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+780)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #34 pc 001f6e3d  /system/lib/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+636)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #35 pc 0021a553  /system/lib/libhwui.so
03-27 21:26:34.592 19636 19636 F DEBUG   :     #36 pc 002390d9  /system/lib/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+312)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #37 pc 0000c6af  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+202)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #38 pc 00071501  /system/lib/libc.so (__pthread_start(void*)+22)
03-27 21:26:34.592 19636 19636 F DEBUG   :     #39 pc 0001de85  /system/lib/libc.so (__start_thread+24)

"dependencies": {
    "@expo/vector-icons": "~10.0.0",
    "@react-native-community/masked-view": "0.1.5",
    "@react-navigation/bottom-tabs": "^5.0.0",
    "@react-navigation/native": "^5.0.0",
    "@react-navigation/stack": "^5.0.0",
    "@react-navigation/web": "~1.0.0-alpha.9",
    "expo": "~36.0.0",
    "expo-asset": "~8.0.0",
    "expo-constants": "~8.0.0",
    "expo-font": "~8.0.0",
    "expo-web-browser": "~8.0.0",
    "react": "~16.9.0",
    "react-dom": "~16.9.0",
    "react-native": "https://github.com/expo/react-native/archive/sdk-36.0.0.tar.gz",
    "react-native-gesture-handler": "~1.5.0",
    "react-native-safe-area-context": "0.6.0",
    "react-native-screens": "2.0.0-alpha.12",
    "react-native-web": "~0.11.7",
    "react-native-webview": "7.4.3"
},

After remove this in App.js, crash stop:

import { enableScreens } from 'react-native-screens'
enableScreens()

Hey @WoLewicki, thank you for taking a look and sorry for the delayed response - I’ve been very busy the last few weeks.

It looks like adding the navigation events as you suggested above has fixed the issue! I’ve tested in both debug and with a release APK and everything looks good 👍

We used a WebView wrapper so it applies to all of our WebViews:

import React, {useState, useEffect} from 'react';
import {WebView as RNWebview} from 'react-native-webview';
import {ViewStyle, View} from 'react-native';
import {useNavigation} from '@react-navigation/native';

import {LoadingSpinner} from '@app/component-library';

import styles from './styles';

interface Props {
  uri: string;
  style?: ViewStyle;
}

export default function Webview({uri, style}: Props) {
  const navigation = useNavigation<any>();
  const [loading, setLoading] = useState(true);
  const [hardware, setHardware] = React.useState(false);

  useEffect(() => {
    const unsubscribe = navigation.addListener('transitionStart', ({data}) => {
      if (data.closing) {
        setHardware(true);
      }
    });

    return unsubscribe;
  }, [navigation]);

  useEffect(() => {
    const unsubscribe = navigation.addListener('transitionEnd', ({data}) => {
      if (!data.closing) {
        setHardware(false);
      }
    });

    return unsubscribe;
  }, [navigation]);

  const onLoad = () => setLoading(false);

  return (
    <>
      <RNWebview
        onLoad={onLoad}
        source={{uri}}
        renderToHardwareTextureAndroid={hardware}
        style={style}
      />
      {loading && (
        <View style={styles.loadingSpinnerContainer}>
          <LoadingSpinner />
        </View>
      )}
    </>
  );
}

Thanks again!

@thanakij it works, but you probably do not want to have the WebView with hardware acceleration enabled all the time. The bug happens when transitioning between screens because Android sets the screen’s layer to hardware for the duration of the transition and WebView having LAYER_TYPE_NONE at that time causes the crash to happen. So maybe subscribing to navigation events would be a way to ensure that for the time of transition, the WebView has the LAYER_TYPE_HARDWARE, and then it changes to LAYER_TYPE_NONE again. It would like probably something like this on native-stack:

  const [hardware, setHardware] = React.useState(false);

  React.useEffect(() => {
    const unsubscribe = navigation.addListener('transitionStart', ({data}) => {
      if (data.closing) {
        setHardware(true);
      }
    });

    return unsubscribe;
  }, [navigation]);

  React.useEffect(() => {
    const unsubscribe = navigation.addListener('transitionEnd', ({data}) => {
      if (!data.closing) {
        setHardware(false);
      }
    });

    return unsubscribe;
  }, [navigation]);

	...
   <WebView renderToHardwareTextureAndroid={hardware} ...

I am not sure if it is enough though.

Hi, can you set renderToHardwareTextureAndroid={true} props for WebView component to see if it resolves the crash? This is just a hypothesis but if this works, it means this is a workaround without having to wait for the settlement from react-native-webview.

Btw, you may have to make sure that you didn’t set androidHardwareAccelerationDisabled props for WebView component.

It seems that the crash is related to the react-native-webview and the problem with the hardware acceleration. You can see related issues here: https://github.com/react-native-community/react-native-webview/issues/1069, https://github.com/wix/react-native-navigation/issues/5702, #214. I am not sure if there exists an easy fix from the side of our library other than suggested in the #214 and it should be fixed from the side of react-native-webview.

We recently added:

import {enableScreens} from 'react-native-screens';
enableScreens();

And noticed some users were getting this issue. We were able to replicate this using the following stack:

AppStack:

• TabStack
  • Home
  • Help
• TermsAndCondtions (loads iframe)

Reproducable flow:

• When first loading the app it loads the Home tab by default
• Navigate to the Help tab
• On the Help tab screen navigate the TermsAndConditions (loads an iframe)
• Press back to the Help tab
• Load Home tab and it crashes

Relevant library versions:

"@react-navigation/bottom-tabs": "5.6.1",
"@react-navigation/native": "5.6.1",
"@react-navigation/stack": "5.6.2",
"react-native": "0.62.2",
"react-native-screens": "2.9.0",

Full Crashlytics issue:

We detected a new fatal issue in libhwui.so: unknown

Crashed: Thread: SIGSEGV  0x0000000000000020
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()
       at (Missing)()

Just to add some additional info, I don’t think it’s related to react-native-webview inherently. I’m getting similar crashes that seem to be caused by a webview created by a banner ad from @react-native-firebase/admob. This means we can’t disable hardware acceleration for the webview. Switching to a normal stack navigator from the native one fixes it as well, but adjusting the height of the banner also causes a crash, so it might be an issue with the native android webview code.

hey @manuhook, I haven’t use react-native-navigation for while, but if they have transition listeners similar to react-navigation it should be possible

I’m experiencing this issue on my Android 9.0 device as well, which is running RN 0.59.8 via Expo v34.

Crash dump:

09-25 22:49:01.461 25438 25438 E crash_dump64: unknown process state: t
09-25 22:49:01.503 25438 25438 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
09-25 22:49:01.504  1202  1202 I /system/bin/tombstoned: received crash request for pid 24821
09-25 22:49:01.504 25438 25438 I crash_dump64: performing dump of process 24748 (target tid = 24821)
09-25 22:49:01.514 25438 25438 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-25 22:49:01.514 25438 25438 F DEBUG   : Build fingerprint: 'samsung/cruiserlteuc/cruiserlteatt:9/PPR1.180610.011/G892AUCS5CSH1:user/release-keys'
09-25 22:49:01.514 25438 25438 F DEBUG   : Revision: '7'
09-25 22:49:01.514 25438 25438 F DEBUG   : ABI: 'arm64'
09-25 22:49:01.514 25438 25438 F DEBUG   : pid: 24748, tid: 24821, name: RenderThread  >>> host.exp.exponent <<<
09-25 22:49:01.514 25438 25438 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x20
09-25 22:49:01.514 25438 25438 F DEBUG   : Cause: null pointer dereference
09-25 22:49:01.514 25438 25438 F DEBUG   :     x0  0000000000000000  x1  00000071099a8f3c  x2  0000000000000002  x3  000000706c329e38
09-25 22:49:01.514 25438 25438 F DEBUG   :     x4  0000000000000000  x5  0000000000000001  x6  0000000000000001  x7  00000000000005a7
09-25 22:49:01.514 25438 25438 F DEBUG   :     x8  0000000000000000  x9  000000705b75bc48  x10 0000007109f13518  x11 000000705b75ac70
09-25 22:49:01.514 25438 25438 F DEBUG   :     x12 000000705b75bc48  x13 0000007109d89100  x14 5228723b342bdaed  x15 0000000000000000
09-25 22:49:01.514 25438 25438 F DEBUG   :     x16 0000007109f3b268  x17 0000007109baac4c  x18 5228723b342bdaed  x19 0000000000000000
09-25 22:49:01.514 25438 25438 F DEBUG   :     x20 0000000000000000  x21 000000704d0167e0  x22 0000000000000000  x23 0000000000000000
09-25 22:49:01.515 25438 25438 F DEBUG   :     x24 0000084000000440  x25 000000706c33e588  x26 0000000000000000  x27 0000000000000000
09-25 22:49:01.515 25438 25438 F DEBUG   :     x28 0000000000000000  x29 000000706c329e00
09-25 22:49:01.515 25438 25438 F DEBUG   :     sp  000000706c329df0  lr  00000071099b1dc4  pc  0000007109baac5c
09-25 22:49:01.537 25438 25438 F DEBUG   :
09-25 22:49:01.537 25438 25438 F DEBUG   : backtrace:
09-25 22:49:01.537 25438 25438 F DEBUG   :     #00 pc 000000000054bc5c  /system/lib64/libhwui.so (SkSurface::getCanvas()+16)
09-25 22:49:02.104  1202  1202 E /system/bin/tombstoned: Tombstone written to: /data/tombstones/tombstone_06
09-25 22:49:02.126  1610 25441 W ActivityManager: crash : host.exp.exponent,0

I would really love to use this library, but I’m not sure what to do now that these crashes are apparent.

@palexs I gave up trying to use it the way it is right now, will wait for a more stable version and compatible with RN 60+

@iagorm, perhaps you could do some testing? There may be some other factors at play here