React-native: 0.62: YellowBox crash on brand new app

[vshab]

Newly created iOS app crashes when press on yellow warning box with uncaught NSInvalidArgumentException exception

Description

Every time I press on YellowBox warning message the iOS app crashes with following trace:

2020-03-31 00:24:58.455305+0700 RN62Crash[9406:6242098] -[NSURLResponse allHeaderFields]: unrecognized selector sent to instance 0x6000022a94e0
2020-03-31 00:24:58.489669+0700 RN62Crash[9406:6242098] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSURLResponse allHeaderFields]: unrecognized selector sent to instance 0x6000022a94e0'
*** First throw call stack:
(
    0   CoreFoundation                      0x00007fff23e3dcce __exceptionPreprocess + 350
    1   libobjc.A.dylib                     0x00007fff50b3b9b2 objc_exception_throw + 48
    2   CoreFoundation                      0x00007fff23e5e9f4 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132
    3   CoreFoundation                      0x00007fff23e426cc ___forwarding___ + 1436
    4   CoreFoundation                      0x00007fff23e449b8 _CF_forwarding_prep_0 + 120
    5   RN62Crash                           0x0000000107eba1fc +[SKResponseInfo shouldStripReponseBodyWithResponse:] + 76
    6   RN62Crash                           0x0000000107eba0d1 -[SKResponseInfo initWithIndentifier:timestamp:response:data:] + 241
    7   RN62Crash                           0x0000000107e93ea9 __71-[FLEXNetworkRecorder recordLoadingFinishedWithRequestID:responseBody:]_block_invoke + 825
    8   libdispatch.dylib                   0x000000010b2daf11 _dispatch_call_block_and_release + 12
    9   libdispatch.dylib                   0x000000010b2dbe8e _dispatch_client_callout + 8
    10  libdispatch.dylib                   0x000000010b2e26fd _dispatch_lane_serial_drain + 788
    11  libdispatch.dylib                   0x000000010b2e328f _dispatch_lane_invoke + 422
    12  libdispatch.dylib                   0x000000010b2eeb65 _dispatch_workloop_worker_thread + 719
    13  libsystem_pthread.dylib             0x00007fff51b9f6fc _pthread_wqthread + 290
    14  libsystem_pthread.dylib             0x00007fff51b9e827 start_wqthread + 15
)
libc++abi.dylib: terminating with uncaught exception of type NSException

React Native version:

System:
    OS: macOS 10.15.3
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Memory: 138.75 MB / 16.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 13.11.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.13.7 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.1 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.4, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
    Android SDK:
      API Levels: 28, 29
      Build Tools: 28.0.3, 29.0.2
      System Images: android-28 | Intel x86 Atom_64, android-29 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 3.6 AI-192.7142.36.36.6241897
    Xcode: 11.4/11E146 - /usr/bin/xcodebuild
  Languages:
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.11.0 => 16.11.0
    react-native: 0.62.0 => 0.62.0
  npmGlobalPackages:
    *react-native*: Not Found

Steps To Reproduce

1. npx react-native init RN62Crash
2. cd RN62Crash
3. add console.warn('Smth') in App's render
4. react-native run-ios --simulator="iPhone 11 Pro"
5. Press on yellow box at bottom
6. App crashes

Expected Results

Yellow box should popup

Snack, code example, screenshot, or link to a repository:

// App.js
const App: () => React$Node = () => {
  console.warn('Something');
  return (
    <>
      <StatusBar barStyle="dark-content" />
...

Repo: https://github.com/vshab/react-native-0.62-crash

[hramos]

Thanks for the report! I was able to reproduce this. It looks like enabling the experimental LogBox allows you to work around this issue:

require('react-native').unstable_enableLogBox()

[rickhanlonii]

Hey @vshab, thanks for reporting.

This issue is caused by the base64 image encoding that we use for the symbolication indicator, which is not supported by the FLEXNetworkRecorder used by Flipper to record network requests for debugging.

To fix this in LogBox, we switched to image files instead of the base64 image data. I'll back port this to YellowBox and we'll patch it to fix.

[rickhanlonii]

Fixed in https://github.com/facebook/react-native/pull/28457

cc @passy - if anyone is using base64 images in the wild then upgrading to 0.62 with Flipper will crash their app. Is it possible to add support for these images so the app doesn't crash?

Here's the crash location:

[rickhanlonii]

cc @alloy @kelset we'll likely want to release a patch for this

[kelset]

thanks for reporting, I'm adding a reference to the commit for 0.62.1

[rickhanlonii]

Note that we won't need a cherry-pick as the PR was directly to the 0.62 branch.

[kelset]

Note that we won't need a cherry-pick as the PR was directly to the 0.62 branch.

oh I see - cool. What about master then? was there a separate PR for applying the same fix there or was already solved?

[alloy]

@kelset YellowBox is gone from master.

[kelset]

gotcha 👍

[mark-plukkido]

@rickhanlonii This was also reported over on the facebook/flipper repo (https://github.com/facebook/flipper/issues/974) and I already sent in a PR. I recommend tracking that issue if you still need base64 data uri support in your RN 0.62 app with Flipper support.

[kelset]

hey folks, we have released 0.62.1 last Friday and this regression should be fixed. Could anyone confirm?

[alloy]

@kelset I’m going to prioritise closing over waiting for verification, we can always re-open! 🚀

[kuzkokov]

hey guys. I don't really want to open a new issue yet, but I also had a problem with YellowBox.

Code:

// App.tsx
YellowBox.ignoreWarnings([
  'Some warning here'
]);

using this code, I'm getting error and a crash in release builds, both iOS and Android:
com.facebook.react.common.JavascriptException: ReferenceError: Can't find variable: LogBoxNotificationContainer

it's not really an issue since I dealt with it by putting the code above intoif (__DEV__) { ... } block, but I'm just not sure if this behavior is intentional.
I'm using RN 0.62.1.

[alloy]

@kuzkokov Please do file a new issue 🙏 If you or others are able to get a fix in soon enough, we may still be able to pick it for another v0.62.x release.

[vicary]

I can confirm this is working.