App crashes on reload in development mode with JSC Engine

[ykliuiev]

Description

After upgrading to react-native-reanimated v3, we noticed that app crashes on reload in development mode with JSC engine. It's reproducible in Example/ app in react-native-reanimated repo and can confirm it does not happen with hermes engine enabled.

Steps to reproduce

1. Disable hermes in Example/ios/Podfile file by changing :hermes_enabled => flags[:hermes_enabled], :fabric_enabled => flags[:fabric_enabled], to :hermes_enabled => false, :fabric_enabled => false,
2. reinstall pods by running pod install command from Example/ios folder
3. build the app and launch it
4. reload the app with R or devmode

Thank you :raised:

Snack or a link to a repository

https://github.com/ykliuiev/reanimated-crash-repro

Reanimated version

3.3.0

React Native version

0.72.3

Platforms

iOS

JavaScript runtime

JSC

Workflow

React Native (without Expo)

Architecture

Paper (Old Architecture)

Build type

Debug mode

Device

iOS simulator

Device model

No response

Acknowledgements

Yes

[victor-asdf]

Same here #4778

[ykliuiev]

@victor-asdf yes, looks like the same but we identified that the root cause is JSC runtime which should help narrow down the potential scope for debugging and investigation.

[victor-asdf]

@ykliuiev Thanks. I have tried all versions of 3.x and it seems happen all the time

[TheMakerOleguch]

@tomekzaw cc

[rajrao1]

iOS App is crashing in iOS 16.5.1 & above in during first launch in Real Device. Not found in the older iOS version.

When: During first launch of the App after installation. Second launch onwards, no crash. It is an intermittent crash and does not happen every first time launch of the app after installation.

OS version: iOS 16.5.1 & above. Not seen in below version react-native-reanimated version: 3.1.0 React Native version: 0.71.7 React Native Type: React Native CLI based app. iPhone: Reproduced in iPhone 13 Pro Max, iPhone 14 Pro Max, iPhone 12, iPhone XR

Podfile changes: Below Podfile changes done to support react-native-firebase library

use_frameworks! :linkage => :static // use static frameworks :hermes_enabled => flags[:hermes_enabled], // No change :fabric_enabled => false // fabric disabled

:flipper_configuration => flipper_config, // filpper commented

Crash Log:

Crashed: com.facebook.react.JavaScript 0 xy_app 0x1bd800 reanimated::ShareableRemoteFunction::~ShareableRemoteFunction() + 409 (jsi.h:409) 1 xy_app 0x1b9b98 std::1::shared_ptr::~shared_ptr[abi:v15006]() + 216 (shared_ptr.h:216) 2 xy_app 0x1baf38 std::1::function::func<reanimated::NativeReanimatedModule::NativeReanimatedModule(std::1::shared_ptr const&, std::__1::shared_ptr const&, std::1::shared_ptr const&, std::1::shared_ptr const&, std::__1::function<facebook::jsi::Value (facebook::jsi::Runtime&, int, facebook::jsi::String const&)>, reanimated::PlatformDepMethodsHolder)::$_1::operator()(facebook::jsi::Runtime&, facebook::jsi::Value const&, facebook::jsi::Value const&) const::'lambda'(), std::1::allocator<reanimated::NativeReanimatedModule::NativeReanimatedModule(std::1::shared_ptr const&, std::__1::shared_ptr const&, std::1::shared_ptr const&, std::1::shared_ptr const&, std::__1::function<facebook::jsi::Value (facebook::jsi::Runtime&, int, facebook::jsi::String const&)>, reanimated::PlatformDepMethodsHolder)::$_1::operator()(facebook::jsi::Runtime&, facebook::jsi::Value const&, facebook::jsi::Value const&) const::'lambda'()>, void ()>::destroy_deallocate() + 256 (new:256) 3 xy_app 0x279d94 std::1::function::func<facebook::react::Instance::JSCallInvoker::scheduleAsync(std::1::function<void ()>&&)::$_3, std::1::allocator<facebook::react::Instance::JSCallInvoker::scheduleAsync(std::1::function<void ()>&&)::$_3>, void (facebook::react::JSExecutor*)>::destroy_deallocate() + 256 (new:256) 4 xy_app 0x283f50 std::1::function::alloc_func<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::1::function<void (facebook::react::JSExecutor)>)::$_8, std::1::allocator<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::1::function<void (facebook::react::JSExecutor)>)::$_8>, void ()>::destroy[abi:v15006]() + 300 (NativeToJsBridge.cpp:300) 5 xy_app 0x283d9c std::1::function::func<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::1::function<void (facebook::react::JSExecutor*)>)::$_8, std::1::allocator<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::1::function<void (facebook::react::JSExecutor*)>)::$_8>, void ()>::destroy_deallocate() + 256 (new:256) 6 xy_app 0x218830 std::__1::shared_ptr<std::1::function<void ()>>::~shared_ptr[abi:v15006]() + 216 (shared_ptr.h:216) 7 xy_app 0x218c4c std::1::function::func<facebook::react::RCTMessageThread::runOnQueue(std::1::function<void ()>&&)::$_1, std::1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::1::function<void ()>&&)::$_1>, void ()>::destroy_deallocate() + 700 (shared_ptr.h:700) 8 libsystem_blocks.dylib 0x2134 _call_dispose_helpers_excp + 48 9 libsystem_blocks.dylib 0x1d64 _Block_release + 252 10 CoreFoundation 0xaa238 CFRunLoopDoBlocks + 404 11 CoreFoundation 0x7a0e8 CFRunLoopRun + 848 12 CoreFoundation 0x7f3ec CFRunLoopRunSpecific + 612 13 xy_app 0x201fb4 +[RCTCxxBridge runRunLoop] + 336 (RCTCxxBridge.mm:336) 14 Foundation 0x5b544 NSThreadstart__ + 716 15 libsystem_pthread.dylib 0x16b8 _pthread_start + 148xy_app 16 libsystem_pthread.dylib 0xb88 thread_start + 8

[Audrey-Ann]

Same here! The app crashes whenever we reload the app in development mode and when hermes = false :(

react-native: ^0.72.3
react-native-reanimated: ^3.3.0

[ykliuiev]

added simple repro just in case https://github.com/ykliuiev/reanimated-crash-repro

[maydersonmellops]

Same here 1464

[DaniyarJakupov]

Crash also happens (ios only) when doing a codepush update in the production app since it reloads the app in order to apply a new bundle. Would be great to at least get a workaround or a patch. cc @piaskowyk

[piaskowyk]

We will check it, but please give us a bit of time 🙏

[dennytosp]

I'm also facing the same issue. Please kindly assist us by performing a quick check. Thank you.

[DaniyarJakupov]

@piaskowyk thank you! The whole stack trace on sentry is huge, but here is some relevant part I think:

Exception Type: EXC_CRASH (SIGABRT)
Crashed Thread: 2

Application Specific Information:
~JSCRuntime > Assertion failed: (objectCounter_ == 0 && "JSCRuntime destroyed with a dangling API object"), function ~JSCRuntime, file JSCRuntime.cpp, line 414.
 > JSCRuntime.cpp > objectCounter_ == 0 && "JSCRuntime destroyed with a dangling API object"

Thread 2 Crashed:
0   libsystem_kernel.dylib          0x3706bd964         __pthread_kill
1   libsystem_pthread.dylib         0x3e2ff3374         pthread_kill
2   libsystem_c.dylib               0x3178a1f4c         abort
3   libsystem_c.dylib               0x3178f8968         __assert_rtn
4   dev                    0x2006bc5ac         facebook::jsc::JSCRuntime::~JSCRuntime
5   dev                    0x2006bc618         [inlined] facebook::jsc::JSCRuntime::~JSCRuntime (JSCRuntime.cpp:403)
6   dev                    0x2006bc618         facebook::jsc::JSCRuntime::~JSCRuntime (JSCRuntime.cpp:403)
7   dev                    0x2005deda4         [inlined] std::__1::__shared_count::__release_shared[abi:v15006] (shared_ptr.h:174)
8   dev                    0x2005deda4         [inlined] std::__1::__shared_weak_count::__release_shared[abi:v15006] (shared_ptr.h:215)
9   dev                    0x2005deda4         [inlined] std::__1::shared_ptr<T>::~shared_ptr[abi:v15006] (shared_ptr.h:702)
10  dev                    0x2005deda4         [inlined] std::__1::shared_ptr<T>::~shared_ptr[abi:v15006] (shared_ptr.h:700)
11  dev                    0x2005deda4         std::__1::shared_ptr<T>::reset[abi:v15006] (shared_ptr.h:768)
12  dev                    0x2005deb34         reanimated::NativeReanimatedModule::~NativeReanimatedModule (NativeReanimatedModule.cpp:202)
13  dev                    0x2005ed8a4         [inlined] std::__1::__shared_count::__release_shared[abi:v15006] (shared_ptr.h:174)
14  dev                    0x2005ed8a4         [inlined] std::__1::__shared_weak_count::__release_shared[abi:v15006] (shared_ptr.h:215)
15  dev                    0x2005ed8a4         std::__1::shared_ptr<T>::~shared_ptr[abi:v15006] (shared_ptr.h:702)
16  dev                    0x2006bf1f8         [inlined] std::__1::shared_ptr<T>::~shared_ptr[abi:v15006] (shared_ptr.h:700)
17  dev                    0x2006bf1f8         [inlined] facebook::jsc::detail::HostObjectProxyBase::~HostObjectProxyBase (JSCRuntime.cpp:751)
18  dev                    0x2006bf1f8         [inlined] facebook::jsc::JSCRuntime::createObject::HostObjectProxy::~HostObjectProxy (JSCRuntime.cpp:768)
19  dev                    0x2006bf1f8         [inlined] facebook::jsc::JSCRuntime::createObject::HostObjectProxy::~HostObjectProxy (JSCRuntime.cpp:768)
20  dev                    0x2006bf1f8         facebook::jsc::JSCRuntime::createObject::HostObjectProxy::finalize (JSCRuntime.cpp:873)
21  JavaScriptCore                  0x317d8ee18         JSC::JSCallbackObject<T>::destroy
22  JavaScriptCore                  0x3183231d0         JSC::MarkedBlock::Handle::specializedSweep<T>
23  JavaScriptCore                  0x31831fba0         JSC::MarkedBlock::Handle::finishSweepKnowingHeapCellType<T>
24  JavaScriptCore                  0x318326c8c         JSC::MarkedBlock::Handle::sweep
25  JavaScriptCore                  0x3182f8d98         JSC::BlockDirectory::lastChanceToFinalize
26  JavaScriptCore                  0x318328ed8         JSC::MarkedSpace::lastChanceToFinalize
27  JavaScriptCore                  0x3182ff514         JSC::Heap::lastChanceToFinalize
28  JavaScriptCore                  0x3188e443c         JSC::VM::~VM
29  JavaScriptCore                  0x3187ac6c8         JSC::JSLockHolder::~JSLockHolder
30  JavaScriptCore                  0x317da0d7c         JSGlobalContextRelease
31  dev                    0x2006bc544         facebook::jsc::JSCRuntime::~JSCRuntime (JSCRuntime.cpp:411)
32  dev                    0x2006bc618         [inlined] facebook::jsc::JSCRuntime::~JSCRuntime (JSCRuntime.cpp:403)
33  dev                    0x2006bc618         facebook::jsc::JSCRuntime::~JSCRuntime (JSCRuntime.cpp:403)
34  dev                    0x2005d9f64         [inlined] std::__1::__shared_count::__release_shared[abi:v15006] (shared_ptr.h:174)
35  dev                    0x2005d9f64         [inlined] std::__1::__shared_weak_count::__release_shared[abi:v15006] (shared_ptr.h:215)
36  dev                    0x2005d9f64         std::__1::shared_ptr<T>::~shared_ptr[abi:v15006] (shared_ptr.h:702)
37  dev                    0x20079887c         [inlined] std::__1::shared_ptr<T>::~shared_ptr[abi:v15006] (shared_ptr.h:700)
38  dev                    0x20079887c         facebook::react::JSIExecutor::~JSIExecutor (JSIExecutor.h:72)
39  dev                    0x200798278         [inlined] facebook::react::JSIExecutor::~JSIExecutor (JSIExecutor.h:72)
40  dev                    0x200798278         facebook::react::JSIExecutor::~JSIExecutor (JSIExecutor.h:72)
41  dev                    0x200656180         [inlined] std::__1::__function::__value_func<T>::operator()[abi:v15006] (function.h:512)
42  dev                    0x200656180         [inlined] std::__1::function<T>::operator() (function.h:1197)
43  dev                    0x200656180         facebook::react::tryAndReturnError (RCTCxxUtils.mm:74)
44  dev                    0x2006612d8         facebook::react::RCTMessageThread::tryFunc (RCTMessageThread.mm:69)
45  dev                    0x2006615a0         facebook::react::RCTMessageThread::runOnQueueSync (RCTMessageThread.mm:92)
46  dev                    0x200776144         facebook::react::NativeToJsBridge::destroy (NativeToJsBridge.cpp:285)
47  dev                    0x20076c2e8         facebook::react::Instance::~Instance (Instance.cpp:39)
48  dev                    0x2006531ec         [inlined] std::__1::default_delete<T>::operator()[abi:v15006] (unique_ptr.h:48)
49  dev                    0x2006531ec         std::__1::__shared_ptr_pointer<T>::__on_zero_shared (shared_ptr.h:263)
50  dev                    0x20064fb84         [inlined] std::__1::__shared_count::__release_shared[abi:v15006] (shared_ptr.h:174)
51  dev                    0x20064fb84         [inlined] std::__1::__shared_weak_count::__release_shared[abi:v15006] (shared_ptr.h:215)
52  dev                    0x20064fb84         [inlined] std::__1::shared_ptr<T>::~shared_ptr[abi:v15006] (shared_ptr.h:702)
53  dev                    0x20064fb84         [inlined] std::__1::shared_ptr<T>::~shared_ptr[abi:v15006] (shared_ptr.h:700)
54  dev                    0x20064fb84         std::__1::shared_ptr<T>::reset[abi:v15006] (shared_ptr.h:768)
55  dev                    0x200650448         __26-[RCTCxxBridge invalidate]_block_invoke (RCTCxxBridge.mm:1309)
56  dev                    0x200656180         [inlined] std::__1::__function::__value_func<T>::operator()[abi:v15006] (function.h:512)
57  dev                    0x200656180         [inlined] std::__1::function<T>::operator() (function.h:1197)
58  dev                    0x200656180         facebook::react::tryAndReturnError (RCTCxxUtils.mm:74)
59  dev                    0x20064bca8         -[RCTCxxBridge _tryAndHandleError:] (RCTCxxBridge.mm:346)
60  Foundation                      0x304a8b454         __NSThreadPerformPerform
61  CoreFoundation                  0x301ac30cc         __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
62  CoreFoundation                  0x301ad3d8c         __CFRunLoopDoSource0
63  CoreFoundation                  0x301a0e094         __CFRunLoopDoSources0
64  CoreFoundation                  0x301a138a0         __CFRunLoopRun
65  CoreFoundation                  0x301a27464         CFRunLoopRunSpecific
66  dev                    0x20064bbd8         +[RCTCxxBridge runRunLoop] (RCTCxxBridge.mm:337)
67  Foundation                      0x304ab6408         __NSThread__start__
68  libsystem_pthread.dylib         0x3e2fed9a0         _pthread_start

Thread 0
0   libsystem_kernel.dylib          0x3706b7504         mach_msg_trap
1   libsystem_kernel.dylib          0x3706b7b98         mach_msg
2   CoreFoundation                  0x301a0f734         __CFRunLoopServiceMachPort
3   CoreFoundation                  0x301a13a28         __CFRunLoopRun
4   CoreFoundation                  0x301a27464         CFRunLoopRunSpecific
5   GraphicsServices                0x33915b388         GSEventRunModal
6   UIKitCore                       0x306870084         -[UIApplication _run]
7   UIKitCore                       0x3065ee954         UIApplicationMain
8   dev                    0x200176ae0         main (main.m:8)
9   <unknown>                       0x1010b5aa4         <redacted>

[dennytosp]

@tomekzaw @piaskowyk Please provide us with feedback, as we are experiencing an issue and need to resolve it quickly 🥺

Thank you very much

[piaskowyk]

This issue is a bit more complicated, Tomek is still working on it in free time.

[JavoxirNazarov]

same here

[JavoxirNazarov]

have anyone find, solution?

[tomekzaw]

Here's an update: we investigated the issue and found the root cause of the problem.

Before we come up with a proper fix, here's a workaround:

JSCRuntime.cpp

 JSCRuntime::~JSCRuntime() {
   // On shutting down and cleaning up: when JSC is actually torn down,
   // it calls JSC::Heap::lastChanceToFinalize internally which
   // finalizes anything left over.  But at this point,
   // JSValueUnprotect() can no longer be called.  We use an
   // atomic<bool> to avoid unsafe unprotects happening after shutdown
   // has started.
   ctxInvalid_ = true;
   JSGlobalContextRelease(ctx_);
-#ifndef NDEBUG
-  assert(
-      objectCounter_ == 0 && "JSCRuntime destroyed with a dangling API object");
-  assert(
-      stringCounter_ == 0 && "JSCRuntime destroyed with a dangling API string");
-#endif
}

[dennytosp]

Thank you very much, you are awesome @tomekzaw

[ugurcanatas]

hey @tomekzaw do you think that without this patch, could this be fixed by using a timeout and reload the app after certain seconds later. I saw this comment in another issue here which is pretty much the same as this one.

[harrisrobin]

Here's an update: we investigated the issue and found the root cause of the problem.

Before we come up with a proper fix, here's a workaround:

JSCRuntime.cpp

 JSCRuntime::~JSCRuntime() {
   // On shutting down and cleaning up: when JSC is actually torn down,
   // it calls JSC::Heap::lastChanceToFinalize internally which
   // finalizes anything left over.  But at this point,
   // JSValueUnprotect() can no longer be called.  We use an
   // atomic<bool> to avoid unsafe unprotects happening after shutdown
   // has started.
   ctxInvalid_ = true;
   JSGlobalContextRelease(ctx_);
-#ifndef NDEBUG
-  assert(
-      objectCounter_ == 0 && "JSCRuntime destroyed with a dangling API object");
-  assert(
-      stringCounter_ == 0 && "JSCRuntime destroyed with a dangling API string");
-#endif
}

thank you for the patch @tomekzaw,

However for anyone attempting this patch, this caused a crash in production for us. The crash was not consistently happening so it may be hard to catch.

[fellenabmb]

I second this, this is a thing. I'll try the suggested workaround meanwhile.

Edit: it does work, but i'm yet to find a way to patch this on the pods postinstall. Any suggestions on how to do it, while we wait for this to be fixed?.

[kioltk]

Any suggestions on how to do it, while we wait for this to be fixed?.

you aware about patch-package ?

[dennytosp]

I second this, this is a thing. I'll try the suggested workaround meanwhile.

Edit: it does work, but i'm yet to find a way to patch this on the pods postinstall. Any suggestions on how to do it, while we wait for this to be fixed?.

@fellenabmb
I hope it helps you. Here is my patch based on @tomekzaw's update.

react-native+0.72.4.patch

diff --git a/node_modules/react-native/ReactCommon/jsc/JSCRuntime.cpp b/node_modules/react-native/ReactCommon/jsc/JSCRuntime.cpp
index 7958519..5ecb903 100644
--- a/node_modules/react-native/ReactCommon/jsc/JSCRuntime.cpp
+++ b/node_modules/react-native/ReactCommon/jsc/JSCRuntime.cpp
@@ -409,12 +409,6 @@ JSCRuntime::~JSCRuntime() {
   // has started.
   ctxInvalid_ = true;
   JSGlobalContextRelease(ctx_);
-#ifndef NDEBUG
-  assert(
-      objectCounter_ == 0 && "JSCRuntime destroyed with a dangling API object");
-  assert(
-      stringCounter_ == 0 && "JSCRuntime destroyed with a dangling API string");
-#endif
 }

 std::shared_ptr<const jsi::PreparedJavaScript> JSCRuntime::prepareJavaScript(

[Eli-Nathan]

@fellenabmb Steps would be:

1. make the changes to that file in node_modules (node_modules/react-native/ReactCommon/jsc/JSCRuntime.cpp)
2. run npx patch-package react-native
3. Add the following to your package.json scripts

   "scripts": {
   +   "postinstall": "npx patch-package"
   }

4. now everytime you run npm install or yarn it will also apply your change
5. Delete your ios/Pods directory
6. Last, run pod install. The RN package imports files straight from node_modules when installing the pods

Note: if you don't have npx installed you'll need to install patch-package in your project and remove the npx prefix from the commands

If you dont want to actually patch the package (since it's probably not recommended to alter the React Native code) in production, you can make the changes manually locally, and start at step 5 above.

[Saad-Bashar]

I am not particularly using react-native-reanimated but I am using react-native-bottom-sheet that uses reanimated. My reanimated version is ^3.5.2 and bottom sheet is ^4, I am using JSC. Not Hermes.

I tried to remove the lines inside /react-native/ReactCommon/jsc/JSCRuntime.cpp and rebuilt the app again. Restarted the metro server as well with cache reset. But the app crashes every time when I reload the app in development mode. Is there anything I am doing wrong here? Thanks a lot for any guidance!

[pavlobu]

the crash also happens on my side with react-native 0.72.6

1. when metro is reloaded with new js code
2. when codepush worked

I'm also using JSC not hermes

I confirm that patch listed above: react-native+0.72.4.patch works for react-native 0.72.6

I created a file called patches/react-native+0.72.6.patch and added in package.json this:

"scripts": {
+   "postinstall": "patch-package"
 }

also I installed patch-package yarn add -D patch-package

[leontiy]

Here's an update: we investigated the issue and found the root cause of the problem.

@tomekzaw is there an update on the fix? The suggested workaround introduces a potential memory corruption, so running the app is not safe / may have unspecified consequences.

[tomekzaw]

@leontiy Unfortunately not and this is unlikely to change as we lean towards supporting only Hermes so JSC is not a priority at the moment.

[dwxw]

I remember we still had issues enabling Hermes for iOS with internationalisation so this isn't great to hear. Will have to see if there's been any progress on getting Hermes to work.

[michaelknoch]

I think most of the Intl APIs are now working with hermes @dwxw . We are still using JSC for iOS because we see significantly lower memory usage (which is quite surprising). It's been a while since I checked the last time. The whole RN ecosystem is moving towards hermes, so I think what @tomekzaw says makes sense.

[dwxw]

It was this: https://github.com/facebook/hermes/issues/1188

[TheMakerOleguch]

Our team was forced to switch back to JSC since Hermes works terribly with Dates (https://github.com/facebook/hermes/issues/930)

[jenskuhrjorgensen]

Am I the only one also having this issue on Android? And for Android the suggested patch doesn't work - probably because Android doesn't use the JSCRuntime.cpp from node_modules but instead from the prebuilt AAR.

[UsamaIrfan]

Facing the same issue

Reanimated version: 3.0.2 React native: 0.71.2

[lucaswitch]

Facing the same issue on 0.73, i think should be a quick fix for that on development mode.

[johnblake18]

I facing same issue on 0.68.2 and react-native-reanimated: 2.14.4

[anhnguyen123]

I facing same issue on "react-native-reanimated": "^3.6.2" and "react-native": "0.71.3"

[anhnguyen123]

I second this, this is a thing. I'll try the suggested workaround meanwhile. Edit: it does work, but i'm yet to find a way to patch this on the pods postinstall. Any suggestions on how to do it, while we wait for this to be fixed?.

@fellenabmb I hope it helps you. Here is my patch based on @tomekzaw's update.

react-native+0.72.4.patch

diff --git a/node_modules/react-native/ReactCommon/jsc/JSCRuntime.cpp b/node_modules/react-native/ReactCommon/jsc/JSCRuntime.cpp
index 7958519..5ecb903 100644
--- a/node_modules/react-native/ReactCommon/jsc/JSCRuntime.cpp
+++ b/node_modules/react-native/ReactCommon/jsc/JSCRuntime.cpp
@@ -409,12 +409,6 @@ JSCRuntime::~JSCRuntime() {
   // has started.
   ctxInvalid_ = true;
   JSGlobalContextRelease(ctx_);
-#ifndef NDEBUG
-  assert(
-      objectCounter_ == 0 && "JSCRuntime destroyed with a dangling API object");
-  assert(
-      stringCounter_ == 0 && "JSCRuntime destroyed with a dangling API string");
-#endif
 }

 std::shared_ptr<const jsi::PreparedJavaScript> JSCRuntime::prepareJavaScript(

in my case "react-native-reanimated": "^3.6.2" and "react-native": "0.71.3" is reload success. thanks

[rushant11]

Here's an update: we investigated the issue and found the root cause of the problem.

Before we come up with a proper fix, here's a workaround:

JSCRuntime.cpp

 JSCRuntime::~JSCRuntime() {
   // On shutting down and cleaning up: when JSC is actually torn down,
   // it calls JSC::Heap::lastChanceToFinalize internally which
   // finalizes anything left over.  But at this point,
   // JSValueUnprotect() can no longer be called.  We use an
   // atomic<bool> to avoid unsafe unprotects happening after shutdown
   // has started.
   ctxInvalid_ = true;
   JSGlobalContextRelease(ctx_);
-#ifndef NDEBUG
-  assert(
-      objectCounter_ == 0 && "JSCRuntime destroyed with a dangling API object");
-  assert(
-      stringCounter_ == 0 && "JSCRuntime destroyed with a dangling API string");
-#endif
}

but what's the relation of this code to our project?

[Reagankm]

I'm also hitting this crash on Android hot reload. There's indifferent Hermes support for react-native-firebase so we're stuck with JSC for now, too.

[lockieluke]

I applied the patch, reinstalled all the Pods still doesn't work

I'm using Expo

[str1ve21]

If you are not facing the Hermes problems above (or they have already been fixed) but you are having trouble with hot reload, then you can try turning it on: https://reactnative.dev/docs/hermes#android

# Use this property to enable or disable the Hermes JS engine.
# If set to false, you will be using JSC instead.
-hermesEnabled=false
+hermesEnabled=true

Fixed for me with - rn 0.72.12 reanimated 3.6.0

[zameschua]

I'm experiencing the same issues

1. The JS bundle reloads after an OTA update -- which throws this error in production as well
2. JSC is a lot faster than Hermes in production which is why we're opting to use JSC. Would love to switch to Hermes but we're waiting for the performance to get a bit better first.
3. The app works perfectly fine with Hermes

Please continue supporting JSC 🙏

rn 0.73.7 reanimated 3.8.1 hermes_enabled = false

[Chimaa123]

"react-native-reanimated": "^3.4.2", "react-native": "0.72.4", This crash was reported on firebase crashlytics report both IOS and android. Crash timing was right after code push installed and before app was about to restart.

[Ajmal0197]

This fixed for me: yarn add react-native-screens react-native-safe-area-context @react-native-masked-view/masked-view

Remember to remove https://www.npmjs.com/package/@react-native-community/masked-view

[scarlac]

@tomekzaw

It reads as if this is a memory leak, which may still happen with Hermes. Unfortunately, runtime performance of Hermes is not good enough to switch over just yet, despite the recent improvements.

If Reanimated wants to drop JSC support that's OK, but can we get an official statement? I need to make decision to stay on Reanimated or not. No hard feelings.

[MartaGalveAthena]

Also seeing this issue in both iOS and Android with RN 72.

Is there a decision on JSC support moving forward? It would be good to know so we can decide if we need to move away from reanimated, those of us who are not planning on moving to Hermes any time soon.

[nateshmbhat]

same issue here. how to fix this ?

[lucaswitch]

same issue here. how to fix this ?

For anyone having this problem, may seem kinda obvious but...

There are only three options here:

1) and best

Upgrade your whole app to hermes, update your reanimated and be good(best solution)

2)

Remove reanimated and deal with lack of packages because a lot of packages depends on reanimated.

3)

Someone from the community do a pull request candidate to fix this issue and give up on future compatibility with newer versions of reanimated(temporary fix for legacy apps)