Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make TurboModuleProviderFunctionType not depend on TurboModuleManager…
… instance Summary: ## Description The C++ lambda that JS invokes to create TurboModules uses `TurboModuleManager`. It is possible for this lambda to outlive the `TurboModuleManager` instance because we delete `TurboModuleManager` on the JS Thread before we schedule the deletion of `CatalystInstanceImpl` object on a neutral third-party background thread. `CatalystInstanceImpl` owns the JS VM instance that owns the C++ lambda. ## [CatalystInstanceImpl.java](https://fburl.com/diffusion/vt4pwjwa) ``` public void destroy() { // ... getReactQueueConfiguration() .getJSQueueThread() .runOnQueue( new Runnable() { Override public void run() { // We need to destroy the TurboModuleManager on the JS Thread if (turboModuleManager != null) { turboModuleManager.onCatalystInstanceDestroy(); } getReactQueueConfiguration() .getUIQueueThread() .runOnQueue( new Runnable() { Override public void run() { // AsyncTask.execute must be executed from the UI Thread AsyncTask.execute( new Runnable() { Override public void run() { // Kill non-UI threads from neutral third party // potentially expensive, so don't run on UI thread // contextHolder is used as a lock to guard against // other users of the JS VM having the VM destroyed // underneath them, so notify them before we reset // Native mJavaScriptContextHolder.clear(); mHybridData.resetNative(); getReactQueueConfiguration().destroy(); Log.d( ReactConstants.TAG, "CatalystInstanceImpl.destroy() end"); ReactMarker.logMarker( ReactMarkerConstants.DESTROY_CATALYST_INSTANCE_END); } }); } }); } }); } }); // ... } ``` The JS thread is also terminated in the neutral third-party thread. Therefore, it should be possible for JS to request a `TurboModule` after `TurboModuleManager` has been destroyed (i.e: JS can try to access memory that was freed). This is why I think we're getting a segfault in T54298358. ## Fix The fix was to wrap all the member variables of TurboModuleManager we use in `TurboModuleProviderFunctionType` in weak references. This way, we can make sure that the memory is valid before using it. Reviewed By: fkgozali Differential Revision: D17539761 fbshipit-source-id: fe527383458a019a4cb9107ec5c3ddd6295ae41c
- Loading branch information