- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Loading status checks…
fix: Memory mismanagement with UI scheduled callbacks (#6900)
## Summary ### What The pattern we used with scheduling callbacks on the UI thread - capturing `this` as a reference - is prone to memory issues. Given such code: ```c++ void WorkletsModuleProxy::scheduleOnUI( jsi::Runtime &rt, const jsi::Value &worklet) { auto shareableWorklet = extractShareableOrThrow<ShareableWorklet>( rt, worklet, "[Worklets] Only worklets can be scheduled to run on UI."); uiScheduler_->scheduleOnUI( [this, shareableWorklet] { this->uiWorkletRuntime_->runGuarded(shareableWorklet); }); } ``` We are likely to run into accessing invalidated memory during a reload. This is due to fact that `WorkletsModuleProxy` is managed by some object held by the instance of React Native. Let's look at the following scenario. 1. `WorkletsModuleProxy` is created on the JS thread and held by the `WorkletsModule` Native Module. 2. `WorkletsModuleProxy::scheduleOnUI` is invoked on the JS thread. The callback is scheduled to be executed on the UI thread. 3. Application's reload gets triggered. A tear down of React Native is starting on the JS thread. 4. `WorkletsModule` gets destroyed. Therefore, `WorkletsModuleProxy` is released and also destroyed. 5. The callback is finally executed on the UI thread by the scheduler. However, `this` has been invalidated. The App crashes. Keep in mind that this isn't exclusive to thread jumps exclusively. Calling `scheduleOnUI` on the UI thread could still result in the callback executing after the memory has been invalidated. `WorkletsModuleProxy` is only an example here, the problem could manifest in all the places where we pass lambdas that capture `this` by reference. ### Fix To fix this I refactored the code so everytime we pass `this` to a scheduled callback, it would be done via a _weak pointer_ which would lock the object and prevent it from being destroyed while the callback is being executed on the UI thread. Perhaps some bits of code don't need this safety measure due to a heuristic existing that guarantees that respective memory won't be invalidated before the callback gets executed. However, I found it extremely challenging and unreliable to come up with these heuristics, as they could possibly break at any future change of the code. ### Affected code: - ReanimatedCommitHook - LayoutAnimationProxy - ReanimatedModuleProxy - WorkletsModuleProxy - WorkletRuntime - NativeProxy ## Test plan Reloading the app no longer causes a crash on a scheduled UI callback.
Showing
21 changed files
with
405 additions
and
233 deletions.
There are no files selected for viewing
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
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
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
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
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
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
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
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
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
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
Oops, something went wrong.