Fix crash due to concurrent writes to frameCallbacks vector #3859
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tomekzaw
approved these changes
Dec 13, 2022
|
Is this the same issue? |
|
@Willham12 could be. any way of reproducing it? what version do you run? |
https://github.com/software-mansion/react-native-reanimated/releases/tag/3.0.0-rc.8 IDK I don't know where exactly it happened. Just have these weird logs in Crashlytics. |
|
At the same time i had also this error: |
|
Yeah, this looks very much like something caused by the bug this PR fixes |
|
Another crash maybe related to this issue: |
This PR changes the way we report errors in development. Previously we'd
use RCTLog native module which would result in a relatively ugly red
screen displaying an error. In addition the stack trace wouldn't be
symbolicated so it was difficult to reason about the root cause of the
problem when the crash happened on the UI runtime.
With this change we provide a symbolicated version of trace to ErroUtil
module which results in the crash being displayed in the same way as it
were to occur on the regular RN runtime.
The main motivation is to provide better guidance for developers about
the crashes on the UI JS runtime as well as to use a familiar UI for
displaying those.
In a nutshell, the method we use relies on an extended version of "eval"
for processing the javascript code when loading on the UI runtime. We
now expose `evalWithSourceUrl` that beside the code also allows for
assiging the source url that is then included in the traces, and
`evalWithSourceMap` (only on hermes) that allows to provide JSON encoded
source map that is then used by the javascript engine to symbolicate the
stack trace.
For JS engines that does not support source maps (JSC), what we do
instead, is that we provide the worklet hash as a part of the source
url, this allows us to recognize which worklet a given stack entry is
coming from and allows us to map the provided line from that worklet
into a line of the whole JS bundle. In order to do so, we now generate
an "error" object in the place where worklet is generated such that we
can get its position in the Javascript bundle.
Below is a summary of changes this PR makes:
1) Changes in plugin focus on removing location metadata (we now use a
string in a format "worklet_7263" where the number is worklet's hash),
adding source maps in a form of JSON encoded string, and adding new
error object to the worklet object which is used to remap worklet line
number into the bundle line number
2) For the latter, we added some additional logic that replaces entries
in the provided error and replaces "worklet_23746:16:2" with the bundle
URL along with the remapped line numbers
3) We now route all JS calls via a new method "guardCall" that adds a
catch statement and passes the exception back to the main JS runtime
where we use ErrorUtils module to trigger the default React Native's
LogBox
4) We extend hermes runtime by exposing `evalWithSourceMap` method
– this method is only added for debug builds and only on hermes.
5) On other runtimes we register additional global method
`evalWIthSourceURL` that makes it possible to provide URLs along the
code that needs to be evaluated.
Run method "something" from the following snippet and expect an error
that should result in a redbox being desplayed. Note that the presented
stack trace should have correct line numbers. See the expected result on
iOS under the snippet. On Android the errors aren't as nicely formatted
but should contain valid trace entries. This needs to be tested on both
JSC and Hermes configurations.
```
function makeWorklet() {
return () => {
'worklet';
throw new Error('Randomly crashing');
};
}
const crashRandomly = makeWorklet();
function anotherWorklet() {
'worklet';
crashRandomly();
}
function something() {
runOnUI(() => {
'worklet';
anotherWorklet();
})();
}
```
Co-authored-by: Tomek Zawadzki <tomasz.zawadzki@swmansion.com>
Co-authored-by: Krzysztof Piaskowy <krzysztof.piaskowy@swmansion.com>
Co-authored-by: Juliusz Wajgelt <49338439+jwajgelt@users.noreply.github.com>
kmagiera
force-pushed
the
shareables_crash_fix
branch
from
c02fecf
to
318373a
Compare
fluiddot
pushed a commit
to wordpress-mobile/react-native-reanimated
that referenced
this pull request
Jun 5, 2023
…-mansion#3859) ## Summary This PR fixes crashes related to concurrent writes to a non-thread-safe frameCallbacks vector. The primary role of frameCallbacks vector was to facilitate requestAnimationFrame calls and hence it has not been designed to allow for other than the main thread to append their callbacks. However, after recent rewrite software-mansion#3722 we introduced a new methods "scheduleOnUI" that was originally meant to interface with a thread-safe scheduler API but was later updated (see c8a77da) to use frameCallbacks in order for errors to be handled using the same code-path the rAF uses. That change introduces a bug in which we'd access and modify that vector from different threads which is undesirable. This PR reverts that change and since software-mansion#3846 provides a better way of handling JS-errors there is no longer need for scheduleOnUI callbacks to go throught the requestAnimationFrame codepath. ## Test plan The easiest way to reproduce the crash we could find was by using BokehExample.tsx on Android. This would normally result in a crash after a couple of seconds of running. With the increased number of circles in that example (e.g. 400) the crash would be almost immediate. This change was tested on that example with 400 circles and the crash would not appear even after some time after launch (few minutes). Co-authored-by: Tomek Zawadzki <tomasz.zawadzki@swmansion.com> Co-authored-by: Krzysztof Piaskowy <krzysztof.piaskowy@swmansion.com> Co-authored-by: Juliusz Wajgelt <49338439+jwajgelt@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR fixes crashes related to concurrent writes to a non-thread-safe frameCallbacks vector. The primary role of frameCallbacks vector was to facilitate requestAnimationFrame calls and hence it has not been designed to allow for other than the main thread to append their callbacks. However, after recent rewrite #3722 we introduced a new methods "scheduleOnUI" that was originally meant to interface with a thread-safe scheduler API but was later updated (see c8a77da) to use frameCallbacks in order for errors to be handled using the same code-path the rAF uses. That change introduces a bug in which we'd access and modify that vector from different threads which is undesirable. This PR reverts that change and since #3846 provides a better way of handling JS-errors there is no longer need for scheduleOnUI callbacks to go throught the requestAnimationFrame codepath.
Test plan
The easiest way to reproduce the crash we could find was by using BokehExample.tsx on Android. This would normally result in a crash after a couple of seconds of running. With the increased number of circles in that example (e.g. 400) the crash would be almost immediate. This change was tested on that example with 400 circles and the crash would not appear even after some time after launch (few minutes).