react-native: 0.62: YellowBox crash on brand new app
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
npx react-native init RN62Crash
- cd RN62Crash
- add
console.warn('Smth')
in App’s render react-native run-ios --simulator="iPhone 11 Pro"
- Press on yellow box at bottom
- 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" />
...
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 8
- Comments: 15 (9 by maintainers)
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:
cc @alloy @kelset we’ll likely want to release a patch for this
hey folks, we have released 0.62.1 last Friday and this regression should be fixed. Could anyone confirm?
@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.
Thanks for the report! I was able to reproduce this. It looks like enabling the experimental LogBox allows you to work around this issue: