Граф коммитов

19 Коммитов

Автор SHA1 Сообщение Дата
ericlewis 01033d16ec Silence Xcode warning (#23880)
Summary:
Fixes a warning in React Xcode proj. Should be a trivial change.

[iOS] [Fixed] - uncaptured lambda warning
Pull Request resolved: https://github.com/facebook/react-native/pull/23880

Differential Revision: D14435848

Pulled By: cpojer

fbshipit-source-id: 83c126c7401ac32b769ff17172f4f4ae576bd771
2019-03-12 22:08:21 -07:00
Pavlos Vinieratos 629708beda Crash reporting heaven (#23691)
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
2019-03-12 19:41:51 -07:00
aleclarson dc893756b8 Properly validate JS->native method calls (#23658)
Summary:
Between invalidating a bridge and suspending its JS thread, native modules may have their methods called.

Only warn when a native module has been invalidated, which happens right before its JS thread is suspended.

Avoid initializing a native module's instance if its bridge is invalidated.

/cc fkgozali f945212447 (commitcomment-32467567)

[iOS] [Fixed] - Properly validate JS->native method calls
Pull Request resolved: https://github.com/facebook/react-native/pull/23658

Differential Revision: D14287594

Pulled By: fkgozali

fbshipit-source-id: 89dd1906a0c55f3f48ba4ff220aac0cddf2eb822
2019-03-04 17:39:53 -08:00
Agustin Collazo 536045276c iOS downgrade invalid bridge warning (#23557)
Summary:
I downgrade the invalid bridge warning because I believe that it is a pain that every time that the JS gets refreshed this warnings are being thrown. If the project increase size and more and more NativeModules are added this warnings just spam the emulator or the device.

I understand the reason of validating if the bridge is valid. However in case of invalidness nothing is done, just the warning is thrown. Hence, the reason of downgrading it to improve the development process.

The error message still exist and it will be in the logs. But it will not spam the development screen

[iOS] [Changed] - Downgrade the Invalid bridge warning message to a log
Pull Request resolved: https://github.com/facebook/react-native/pull/23557

Differential Revision: D14161290

Pulled By: cpojer

fbshipit-source-id: e5608a9b2db5625309fd18d133fe69a9013043f3
2019-02-20 19:07:36 -08:00
Héctor Ramos 1151c096da Update copyright headers to yearless format
Summary: This change drops the year from the copyright headers and the LICENSE file.

Reviewed By: yungsters

Differential Revision: D9727774

fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
2018-09-11 15:33:07 -07:00
Kevin Gozali f945212447 iOS downgrade error to warning when invoking native module with invalid bridge
Summary: A bunch of flows including JS reload and e2e tests seem to hit the race condition, causing redbox. For now, make it a warning to unblock.

Differential Revision: D9327418

fbshipit-source-id: a72b378d88f7566268fd9415fbd34225c8b931e7
2018-08-14 18:19:01 -07:00
Kevin Gozali 29245e96cb iOS: prevent nativemodule access from JS if bridge is no longer valid
Summary: This helps prevent race condition where JS calls to NativeModules got queued and executed while the bridge is invalidating itself, causing assertion failures in test setup (for example). It won't prevent it 100% of the time, due to threading (and adding lock is expensive for each nativemodule call).

Reviewed By: yungsters

Differential Revision: D9231636

fbshipit-source-id: 298eaf52ffa4b84108184124e75b206b9ca7a41d
2018-08-09 12:17:07 -07:00
Sophie Alpert 1490ab12ef Update license headers for MIT license
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
2018-02-16 18:31:53 -08:00
Alex Dvornikov 0ac5a5230c Make RCTNativeModule::invokeInner explicitely return folly::none in case of error
Differential Revision: D6347967

fbshipit-source-id: 88788da321ca75d20b6c1a8e3d41642af7c6155e
2017-11-17 03:17:20 -08:00
Alex Dvornikov d07279c978 Remove usage of "this" in a callback in RCTNativeModule
Summary: As RCTNativeModule can be destructed at any time, it's unsafe to capture "this" in a callback.

Reviewed By: javache

Differential Revision: D5963728

fbshipit-source-id: c80a01c851d97813e4fead2b31c442eaeb8ae204
2017-10-04 06:00:09 -07:00
Alex Dvornikov 47f6068b16 Log call stack symbols in case of native module method's failure
Differential Revision: D5921069

fbshipit-source-id: c386a836e6f3c314d668e02f3bae243dadcab6e3
2017-09-27 10:00:33 -07:00
Alex Dvornikov 29e7659111 Use const reference in RCTNativeModule::invokeInner
Reviewed By: mhorowitz

Differential Revision: D5909088

fbshipit-source-id: 3104e3d0a4b29d457c3c7fad2a29e2f0943b478d
2017-09-25 20:39:16 -07:00
Pieter De Baets cb12080179 Replace exported method registration with statically allocated struct
Reviewed By: fromcelticpark

Differential Revision: D5389383

fbshipit-source-id: 9eb29b254b616574966b43ad24aa880d44589652
2017-07-24 07:01:53 -07:00
Pieter De Baets f1cbb11620 Replace -[RCTConvert folly_dynamic:] with direct calls to convertIdToFollyDynamic
Reviewed By: kathryngray

Differential Revision: D5355734

fbshipit-source-id: 4ba1533b75c8e271a86a2d5cc3a3354e52f83db2
2017-07-10 05:31:04 -07:00
Pieter De Baets 6221053179 Improve systrace markers
Reviewed By: mhorowitz

Differential Revision: D4860135

fbshipit-source-id: ce963010883e6b9cc8e34f7ff01b4018cd195eba
2017-05-12 18:07:49 -07:00
Alex Dvornikov db0c22192c Added support for synchronous methods in native modules on iOS
Reviewed By: javache

Differential Revision: D4947556

fbshipit-source-id: 0ef73dc5d741201e59fef1fc048809afc65c75b5
2017-04-27 12:03:30 -07:00
Pieter De Baets 34bc6bd2ae Drop support for webworkers
Reviewed By: AaaChiuuu

Differential Revision: D4916449

fbshipit-source-id: a447233d3b7cfee98db2ce00f1c0505d513e2429
2017-04-25 05:37:54 -07:00
Pieter De Baets 2336ac299c Improve constant extraction from RCTNativeModule
Reviewed By: dcaspi

Differential Revision: D4829671

fbshipit-source-id: 6b1cef1d31c7d8981c6f1e304d3742e885f8a83b
2017-04-08 15:18:08 -07:00
Pieter De Baets ce270220e4 Extract module registry creation to helper
Reviewed By: mhorowitz

Differential Revision: D4721817

fbshipit-source-id: 2fa17ca5317a57d429aa75d6c1865932af27e02f
2017-03-17 07:08:14 -07:00