Summary:
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
I have used RN for a long time, and for all this time, crash reporting has been less great than native development crash reporting. At some point, companies like sentry, bugsnag and a bunch of others started supporting sourcemaps for js crashes in RN, which helped a lot.
But native crashes were (and still are) much harder to diagnose.
..Until now :D
I have make a repo of a sample RN app, included this PR in it, and some code and screenshots to help.
The repo is [here](https://github.com/pvinis/react-native-project-with-crash-heaven-pr).
I was trying to get good crash reports from native crashes in iOS for a looong time. I spoke with people in sentry, in bugsnag and more, and I could not get this solved. There was no clear way to get the **native** crashed to display correctly.
I made two repos here, one for [sentry](https://github.com/pvinis/SentryBadStack) and one for [bugsnag](https://github.com/pvinis/BugsnagBadStack), demonstrating the correct js handling and the bad native handling.
After all this, and talks with their support, twitter etc, I investigated further, on **why** this was happening. I thought there must be some reason that native crashes look bad in all the tools, and in the same way. Maybe it's not their fault, or up to them to fix it, or maybe they didn't have the experience to fix it.
In a test project I created, I checked what's up with the `RCTFatalException`, and I found out that the React Native code is catching the `NSException`s that come from any native modules of a RN app and converting it into an string and sending it to `RCTFatal` that created an `NSError` out of that string. Then it checks if the app has set a fatal error handler and if not, goes ahead and throws that `NSError`.
The problem here is that `NSException` has a bunch more info that the resulting `NSError` is missing or is altering. Turning the callstack into a string renders crash reporting tools useless as they are missing the original place the exception was thrown, symbols, return addresses etc. In both repos above it can be seen that both tools were thinking that the error happened somewhere in the `RCTFatal` function, and it did, since we create it there, losing all the previous useful info of the original exception. That leaves us with just a very long name including a callstack, but very hard to actually map this to the code and dsym.
I added a fatal exception handler, that mirrors the fatal error handler, as the error handler is used around React Native internal code.
Then I stopped making a string out of the original `NSException` and calling `RCTFatal`, and I simply throw the exception. This way no info is lost!
Finally, I added some code examples of native and js crashes and added a part in the `RNTester` app, so people can see how a js and a native error look like while debugging, as well as try to compile the app in release mode and see how the crash report would look like if they connect it to bugsnag or sentry or their tool of choice.
I have attached some images at the bottom of this PR, and you can find some in the 3 repos I linked above.
[iOS] [Fixed] - Changed the way iOS native module exceptions get handled. Instead of making them into an `NSError` and lose the context and callstack, we keep them as `NSException`s and propagate them.
[General] [Added] - Example code for native crashes in iOS and Android, with buttons on RNTester, so developers can see how these look when debugging, as well as the crash reports in release mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/23691
Reviewed By: fkgozali
Differential Revision: D14276366
Pulled By: cpojer
fbshipit-source-id: b308d5608e1432d7676447347ae77c0721094e62
Summary:
Fixes#22530
As described in the issue, the previous behavior for the `RCTFatal` macro was to truncate the `reason` on the resulting `NSException` to 75 characters. This would ensure the reason would fit on a single line, but resulted in issues debugging errors that occurred in the wild, as many crash logging tools (like Sentry) discard the `name` value of the exception and use the `reason` as their primary identifier. At 75 characters, useful information like the location of the error would usually be truncated.
- [x] This extends the truncation threshold to 175 characters, which should be short enough to prevent full-screen-takeover length errors, but long enough to provide useful context to the error.
- [x] This adds a `userInfo` value to the resulting `NSException`. It copies over the `userInfo` from the `NSError` passed to the macro, and adds an "untruncated message" value that contains the untruncated version of the `NSException`'s reason.
[iOS] [Changed] - RCTFatalExceptions now include more information in their reason and a userInfo.
<!--
CATEGORY may be:
- [General]
- [iOS]
- [Android]
TYPE may be:
- [Added] for new features.
- [Changed] for changes in existing functionality.
- [Deprecated] for soon-to-be removed features.
- [Removed] for now removed features.
- [Fixed] for any bug fixes.
- [Security] in case of vulnerabilities.
For more detail, see https://keepachangelog.com/en/1.0.0/#how
MESSAGE may answer "what and why" on a feature level. Use this to briefly tell React Native users about notable changes.
EXAMPLES:
[General] [Added] - Add snapToOffsets prop to ScrollView component
[General] [Fixed] - Fix various issues in snapToInterval on ScrollView component
[iOS] [Fixed] - Fix crash in RCTImagePicker
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/22532
Differential Revision: D13373469
Pulled By: cpojer
fbshipit-source-id: ac140d14ce76e1664869437c2c178bdd65ab6e0e
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
As per https://twitter.com/olebegemann/status/738656134731599872, our use of "main thread" to mean "main queue" seems to be unsafe.
This diff replaces the `NSThread.isMainQueue` checks with dispatch_get_specific(), which is the recommended approach.
I've also replaced all use of "MainThread" terminology with "MainQueue", and taken the opportunity to deprecate the "sync" param of `RCTExecuteOnMainThread()`, which, while we do still use it in a few places, is incredibly unsafe and shouldn't be encouraged.
Reviewed By: javache
Differential Revision: D3384910
fbshipit-source-id: ea7c216013372267b82eb25a38db5eb4cd46a089
Summary: I changed the format slightly of the exception being generated in RCTFatal, so we we're catching and rethrowing it, which left some useful information of the error stack.
public
Reviewed By: majak
Differential Revision: D2631341
fb-gh-sync-id: feb4939f58014171a55cd74f20f57bcd6dfddc1e
Summary: public
Add RCTFatal for reporting fatal runtime conditions. This centralizes failure handling to one function and allows you to customize how they should be handled. RCTFatal will be logged to the console and as a redbox and will also be triggered by fatal exceptions coming from RCTExceptionsManager.
Note that there is no RCTLogFatal, since just logging the fatal condition does not allow us to handle it consistently.
Reviewed By: nicklockwood
Differential Revision: D2615490
fb-gh-sync-id: 7d8e134419e10a8fb549297054ad955db3f6bee0
Summary: public
Added lightweight genarics annotations to make the code more readable and help the compiler catch bugs.
Fixed some type bugs and improved bridge validation in a few places.
Reviewed By: javache
Differential Revision: D2600189
fb-gh-sync-id: f81e22f2cdc107bf8d0b15deec6d5b83aacc5b56
Summary:
I encountered a crash when `RCTCurrentThreadName` called `dispatch_get_current_queue`. There are reports of it crashing e.g. https://github.com/CocoaLumberjack/CocoaLumberjack/issues/108 so better not to call it at all, plus it is deprecated.
Since we still want helpful debugging information, use `DISPATCH_CURRENT_QUEUE_LABEL` instead. It's kind of strange that this constant is defined to be NULL and the docs for `dispatch_get_queue_label` say not to pass in NULL, but in practice `DISPATCH_CURRENT_QUEUE_LABEL` is provided by the iOS SDK and works correctly.
Closes https://github.com/facebook/react-native/pull/1868
Github Author: James Ide <ide@jameside.com>
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
Summary:
@public
Add `RCTAssertThread` to `RCTAssert.h` for convenience when checking the current/queue,
it accepts either a `NSString *`, `NSThread *` or `dispatch_queue_t` as the object to be checked
Also add a check to `-[RCTUIManager addUIBlock:]` - There was a discussion on github (https://github.com/facebook/react-native/issues/1365)
due to the weird behavior caused by calling it from a different thread/queue (it might be added after `batchDidComplete` has been called
and will just be dispatched on the next call from JS to objc)
Test Plan:
Change `-[RCTAnimationExperimentalManager methodQueue]` to return `dispatch_get_main_queue()` and run the 2048 example,
it should dispatch with a helpful message (screenshot on the comments)
Pavlos Vinieratos
Alex Dvornikov
Zack Sheppard
Héctor Ramos
Sophie Alpert
Marc Horowitz
Nick Lockwood
David Aurelio
Pieter De Baets
James Ide
Alex Akers
Tadeu Zagallo