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

App does not crash as expected #26309

Closed
remanation opened this issue Sep 3, 2019 · 6 comments
Closed

App does not crash as expected #26309

remanation opened this issue Sep 3, 2019 · 6 comments
Labels
Bug Resolution: Locked This issue was locked by the bot.

Comments

@remanation
Copy link

remanation commented Sep 3, 2019

We have been investigating issues in our app where we just see a white screen and no crash is logged. Goes for both Android and iOS

The issue seem to be related to the use of async/await or promises.

We have found that we can reproduce the white screen issue locally when using async/await or promises.

The issue can be reproduced with the following code (tried to simplify it as much as possible). Replace App.js in a new project with the following:

/**
 * Sample React Native App
 * https://github.com/facebook/react-native
 *
 * @format
 * @flow
 */

import React, {Fragment} from 'react';
import {Text} from 'react-native';

class App extends React.Component {
  state = {isMounted: false};

  async componentDidMount() {
    await Promise.resolve(1);
    this.setState({isMounted: true});
  }

  render() {
    if (this.state.isMounted) {
      this.state.isMounted.test();
    }
    return (
      <Fragment>
        <Text>test</Text>
      </Fragment>
    );
  }
}

export default App;

I also pushed a test project on github

I would expect the app to crash as isMounted does not contains a test method.

When running locally I get the red box stating that an error occurred as expected

TypeError: this.state.isMounted.test is not a function. (In 'this.state.isMounted.test()', 'this.state.isMounted.test' is undefined)

This error is located at:
    in App (at renderApplication.js:40)
    in RCTView (at View.js:35)
    in View (at AppContainer.js:98)
    in RCTView (at View.js:35)
    in View (at AppContainer.js:115)
    in AppContainer (at renderApplication.js:39)

...

but when running a release build the app does not crash and no error is reported. This makes it very hard for us to find and fix issues like this as we are totally blind.

If I comment out

await Promise.resolve(1);

It crash as expected in a release build

Are we wrong in assuming that the above code should result in an app crash?

React Native version:

System:
OS: macOS 10.14.5
CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
Memory: 2.97 GB / 32.00 GB
Shell: 5.6.2 - /usr/local/bin/zsh
Binaries:
Node: 12.3.1 - /usr/local/bin/node
Yarn: 1.15.2 - /usr/local/bin/yarn
npm: 6.11.2 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.4, macOS 10.14, tvOS 12.4, watchOS 5.3
Android SDK:
API Levels: 23, 26, 27, 28
Build Tools: 26.0.3, 27.0.3, 28.0.3, 29.0.0
System Images: android-23 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom
IDEs:
Android Studio: 3.2 AI-181.5540.7.32.5056338
Xcode: 10.3/10G8 - /usr/bin/xcodebuild
npmPackages:
react: 16.8.6 => 16.8.6
react-native: 0.60.5 => 0.60.5

@remanation remanation added the Bug label Sep 3, 2019
@remanation remanation changed the title Errors expected to crash the app does not result in app crash App does not crash as expected Sep 3, 2019
@bartolkaruza
Copy link

Hi there, for production builds you can use error boundaries to show an error page on problems inside the render functions of your view and a crash reporting tool (Bugsnag, Sentry, etc..) for debugging. The reason you are not seeing a hard crash of the app is that the view is not rendered correctly on the JS side, so no view information is sent to the native side. There are no crashes on the native side caused by this, native crashes are what you would call a hard crash. This looks like expected behavior to me, which you can deal with by handling errors differently.

@remanation
Copy link
Author

Thanks for the reply. Error boundaries did actual catch the error. I just still don't understand why there is a difference in using promises (async/await) and not. If promises is not used the app does actual crash on the native side.

@peterjuras
Copy link
Contributor

I'm facing the same issue in two react-native projects, where previously errors on the javascript side led to hard crashes, allowing our crash reporting tool to receive the error.

Was this behavior changed in some release? Having hard crashes allowed us to identify and fix issues more quickly.

@mtr1012
Copy link

mtr1012 commented Apr 18, 2020

Happen on my project. Instead of crash. App show white screen and crashlog can't receive crash event

@mtr1012
Copy link

mtr1012 commented Apr 18, 2020

Can you resolve the issue @remanation

@remanation
Copy link
Author

remanation commented Apr 21, 2020

@mtr1012.
As the product we use for crash logging did not have an easy way of logging custom hard-crashes, using Error boundaries was not really a solution for us at that point. So what we ended up doing was writing a custom uncaught exception manager module for both iOS and Android that made sure any unhandled (soft) exceptions was treated as a hard-exception that made the app crash.
He have a task at looking into what can be done instead of having a custom way of handling this - but we had to do a quick fix to find out what was causing our "white" screens - so I would not really recommend our approach :-)
But if you want I can properly dig out some code for inspiration.

If you are using for instance BugSnag I know they have an ErrorBoundary component for this scenario

@facebook facebook locked as resolved and limited conversation to collaborators Oct 4, 2021
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Oct 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

5 participants