fix: Memory mismanagement with UI scheduled callbacks

[tjzel]

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:

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.

[tjzel]

weak_from_this can only be used after the object has been instantiated. Therefore, all callbacks that use weak_from_this must be created in a subsequent init method.

[tjzel]

We can't invalidate it here because relevant callbacks might still need it. Once they get executed and cleaned up the destructor will take care of things.

[tjzel]

weak_from_this can only be used after the object has been instantiated. Therefore, all callbacks that use weak_from_this must be created in a subsequent init method.

[tjzel]

I couldn't decide if I prefer the syntax

weakThis - strongThis

or

weak<object name> - <object name>

Do you have any preferences?

[bartlomiejbloniarz]

i think weak<Object name> is more clear