EXC_BAD_ACCESS in production after upgrading to 0.79.6

[matinzd]

Description

We have got a lot a bunch of unhandled errors in sentry and some users are experiencing crashes after enabling new architecture and moving to RN 0.79.6:

https://lendo.sentry.io/share/issue/15101300672940039f9334b6a3dbd6cf/

Exception 1, Code 1, Subcode 2014344570531660876 >
KERN_INVALID_ADDRESS at 0x1bf463b6e5c6c44c.

Hermes engine in Podfile.lock is also updated to the latest version and it's locked to 0.79.6.

It's happening for 9 users since 2 weeks ago that we released.

Steps to reproduce

This is very hard to reproduce. I am not sure what has happened.

React Native Version

0.79.6

Affected Platforms

Runtime - iOS

Output of npx @react-native-community/cli info

info Fetching system and libraries information...
System:
  OS: macOS 15.6.1
  CPU: (10) arm64 Apple M1 Pro
  Memory: 134.56 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 22.18.0
    path: ~/.nvm/versions/node/v22.18.0/bin/node
  Yarn:
    version: 1.22.19
    path: ~/.nvm/versions/node/v22.18.0/bin/yarn
  npm:
    version: 10.9.3
    path: ~/.nvm/versions/node/v22.18.0/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.16.1
    path: /Users/xxxx/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.5
      - iOS 18.5
      - macOS 15.5
      - tvOS 18.5
      - visionOS 2.5
      - watchOS 11.5
  Android SDK:
    API Levels:
      - "28"
      - "29"
      - "30"
      - "31"
      - "33"
      - "34"
      - "35"
      - "36"
    Build Tools:
      - 28.0.3
      - 29.0.2
      - 30.0.3
      - 33.0.1
      - 34.0.0
      - 35.0.0
      - 36.0.0
    System Images:
      - android-33-ext4 | Google Play ARM 64 v8a
      - android-34-ext12 | Google Play ARM 64 v8a
      - android-34 | Google APIs ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2024.3 AI-243.26053.27.2432.13536105
  Xcode:
    version: 16.4/16F6
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.11
    path: /usr/bin/javac
  Ruby:
    version: 3.2.2
    path: /Users/xxxx/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 18.0.0
    wanted: 18.0.0
  react:
    installed: 19.0.0
    wanted: 19.0.0
  react-native:
    installed: 0.79.6
    wanted: 0.79.6
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

info React Native v0.81.4 is now available (your project is running on v0.79.6).
info Changelog: https://github.com/facebook/react-native/releases/tag/v0.81.4
info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.79.6&to=0.81.4
info For more info, check out "https://reactnative.dev/docs/upgrading?os=macos".

Stacktrace or Logs

OS Version: iOS 18.6.2 (22G100)
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: SEGV_NOOP at 0x1bf463b6e5c6c44c
Crashed Thread: 8

Application Specific Information:
Exception 1, Code 1, Subcode 2014344570531660876 >
KERN_INVALID_ADDRESS at 0x1bf463b6e5c6c44c.

Thread 8 Crashed:
0   KreddyMobile                    0x2039cd910         [inlined] facebook::react::Scheduler::uiManagerDidFinishTransaction::lambda::operator() (Scheduler.cpp:266)
1   KreddyMobile                    0x2039cd910         [inlined] std::__1::__invoke[abi:ne180100]<T> (invoke.h:344)
2   KreddyMobile                    0x2039cd910         [inlined] std::__1::__invoke_void_return_wrapper<T>::__call[abi:ne180100]<T> (invoke.h:419)
3   KreddyMobile                    0x2039cd910         [inlined] std::__1::__function::__alloc_func<T>::operator()[abi:ne180100] (function.h:169)
4   KreddyMobile                    0x2039cd910         std::__1::__function::__func<T>::operator() (function.h:311)
5   KreddyMobile                    0x203a77f5c         facebook::react::RuntimeScheduler_Modern::runEventLoopTick (RuntimeScheduler_Modern.cpp:340)
6   KreddyMobile                    0x203a77c30         facebook::react::RuntimeScheduler_Modern::runEventLoop (RuntimeScheduler_Modern.cpp:271)
7   KreddyMobile                    0x203a488cc         [inlined] std::__1::__function::__value_func<T>::operator()[abi:ne180100] (function.h:428)
8   KreddyMobile                    0x203a488cc         [inlined] std::__1::function<T>::operator() (function.h:981)
9   KreddyMobile                    0x203a488cc         [inlined] const::lambda::operator() (ReactInstance.cpp:83)
10  KreddyMobile                    0x203a488cc         [inlined] std::__1::__invoke[abi:ne180100]<T> (invoke.h:344)
11  KreddyMobile                    0x203a488cc         [inlined] std::__1::__invoke_void_return_wrapper<T>::__call[abi:ne180100]<T> (invoke.h:419)
12  KreddyMobile                    0x203a488cc         [inlined] std::__1::__function::__alloc_func<T>::operator()[abi:ne180100] (function.h:169)
13  KreddyMobile                    0x203a488cc         std::__1::__function::__func<T>::operator() (function.h:311)
14  KreddyMobile                    0x2038edbe8         [inlined] std::__1::__function::__value_func<T>::operator()[abi:ne180100] (function.h:428)
15  KreddyMobile                    0x2038edbe8         [inlined] std::__1::function<T>::operator() (function.h:981)
16  KreddyMobile                    0x2038edbe8         facebook::react::tryAndReturnError (RCTCxxUtils.mm:73)
17  KreddyMobile                    0x2038fc084         facebook::react::RCTMessageThread::tryFunc (RCTMessageThread.mm:68)
18  KreddyMobile                    0x2038fbe88         [inlined] std::__1::__function::__value_func<T>::operator()[abi:ne180100] (function.h:428)
19  KreddyMobile                    0x2038fbe88         [inlined] std::__1::function<T>::operator() (function.h:981)
20  KreddyMobile                    0x2038fbe88         facebook::react::RCTMessageThread::runAsync (RCTMessageThread.mm:44)
21  CoreFoundation                  0x31f0a884c         __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__
22  CoreFoundation                  0x31f04b024         __CFRunLoopDoBlocks
23  CoreFoundation                  0x31f04c524         __CFRunLoopRun
24  CoreFoundation                  0x31f04dad8         CFRunLoopRunSpecific
25  KreddyMobile                    0x203a445a4         +[RCTJSThreadManager runRunLoop] (RCTJSThreadManager.mm:102)
26  Foundation                      0x31c9a3800         __NSThread__start__
27  libsystem_pthread.dylib         0x4339ab340         _pthread_start

MANDATORY Reproducer

N/A

Screenshots and Videos

No response

[react-native-bot]

[!WARNING] Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:

• For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
• If your bug is UI related: a Snack
• If your bug is build/upgrade related: a project using our Reproducer Template

You can read more about about it on our website: How to report a bug.

[emandres]

I'm getting the same error. Been throwing things at the wall for two weeks on this, so far. Interested to see what the RN team has to say.

[zeta92]

Hey I am getting the same error, I can't reproduce it but is happening to the 5% of our users

[abhayagrawal-fareye]

facebook::react::TelemetryController::pullTransaction(std::__1::function<void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)> const&, std::__1::function<void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)> const&, std::__1::function<void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)> const&) const EXC_BAD_ACCESS (KERN_INVALID_ADDRESS)

Facing similar errors in react native 0.77.3

[Brma1048]

also getting this error. React Native: 0.79.6 New Arch: true

[ElieGhanimeh]

Also getting this error React Native: 0.80.0 New Arch: true

The app is being used by over 500 users and most probably more, only happening to a few.

[SanjayConverge]

Same issue after upgrading from v0.71.19 - v0.80.1 . It is happening to some random users on iOS.

Crash logged in the Sentry :

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 24 > KERN_INVALID_ADDRESS at 0x18 ; facebook::react::concreteComponentDescriptorConstructor<T>

[emandres]

So, I've been fighting these for the better part of a month now. Since we don't seem to be getting a response from the React Native team, I thought I'd share what I've learned.

I was able to clean up a lot of these errors by making sure that the app doesn't try to update components after they've been removed from the screen. There are a lot of things to check for this, but offhand:

• Make sure you clean up event listeners in your useEffect hooks;
• Asynchronous code needs to check that the component is still mounted after each await
• Make sure you cancel any setInterval calls on unmount; same goes for setTimeout

I've managed to reduce the number of these errors quite a bit with the above tactics. We've narrowed down the majority of the remaining errors to something being thrown during the Expo Update process. It seems like the update downloads just fine, but once the app reboots to apply the update we get the error.

Another thing to be aware of is that ErrorBoundary only works for exceptions that are thrown during the React component lifecycle. That means that most errors thrown from async code and event handlers don't get caught. I found recently that there is a way to set up a global error handler in React Native: ErrorUtils.setGlobalHandler. This change is still to be proven in production, so take it with a grain of salt.

The only other bit of wisdom I can impart is to work on your app's observability. We were flying blind because we didn't have the DSYM files uploaded to Sentry, and any over-the-air updates we did after the initial native release weren't getting the source map files.

[ElieGhanimeh]

So, I've been fighting these for the better part of a month now. Since we don't seem to be getting a response from the React Native team, I thought I'd share what I've learned.

I was able to clean up a lot of these errors by making sure that the app doesn't try to update components after they've been removed from the screen. There are a lot of things to check for this, but offhand:

• Make sure you clean up event listeners in your useEffect hooks;
• Asynchronous code needs to check that the component is still mounted after each await
• Make sure you cancel any setInterval calls on unmount; same goes for setTimeout

I've managed to reduce the number of these errors quite a bit with the above tactics. We've narrowed down the majority of the remaining errors to something being thrown during the Expo Update process. It seems like the update downloads just fine, but once the app reboots to apply the update we get the error.

Another thing to be aware of is that ErrorBoundary only works for exceptions that are thrown during the React component lifecycle. That means that most errors thrown from async code and event handlers don't get caught. I found recently that there is a way to set up a global error handler in React Native: ErrorUtils.setGlobalHandler. This change is still to be proven in production, so take it with a grain of salt.

The only other bit of wisdom I can impart is to work on your app's observability. We were flying blind because we didn't have the DSYM files uploaded to Sentry, and any over-the-air updates we did after the initial native release weren't getting the source map files.

Thank you for sharing! I think it's happening for me because of a remote config check using Firebase, not entirely sure though. It's only happening on production as well after days of usage, I can't really replicate the error on my simulator to debug it furthermore which is kinda annoying.

[Brma1048]

@cortinico is it possible that somebody of the react native team can take a look into this issue?

[cortinico]

@cortinico is it possible that somebody of the react native team can take a look into this issue?

Without a repro: highly unlikely

[matinzd]

Are there any ways we can try to reproduce this @cortinico ? This is only affecting some users in productions and it's very random. I tried to go through our Sentry events but it's very hard to pinpoint what's causing the crash.

[cortinico]

Are there any ways we can try to reproduce this @cortinico ? This is only affecting some users in productions and it's very random. I tried to go through our Sentry events but it's very hard to pinpoint what's causing the crash.

I sadly have no context on why this crash is happening. If you have access to Sentry you should try to understand under which circumstances this crash reproduces and attempt to reproduce it locally.

[koreus7]

I know EXC_BAD_ACCESS is very generic but we have also experienced a large spike in these errors since updating to 0.81.4 (new arch). It's really difficult to get reproduction steps.

All the crashes we have seen are in hermes

I'm attaching some stack traces here in case someone from RN team can see any pattern.

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 6 >
KERN_INVALID_ADDRESS at 0x6.
  hermes              0x10706d1f8  hermes::vm::KindAndSize::getSize (GCCell.h:46)
  hermes              0x10706d1f8  hermes::vm::GCCell::getAllocatedSize (GCCell.h:118)
  hermes              0x10706d1f8  hermes::vm::ArrayStorageBase<T>::capacity (ArrayStorage.h:169)
  hermes              0x10706d1f8  hermes::vm::JSObject::allocateNewSlotStorage (JSObject.cpp:258)
  hermes              0x1070727f8  hermes::vm::JSObject::addOwnPropertyImpl (JSObject.cpp:2760)
  hermes              0x1070727f8  hermes::vm::JSObject::addOwnPropertyImpl (JSObject.cpp:2760)
  hermes              0x107051c7c  hermes::vm::BoundFunction::initializeLengthAndName_RJS (Callable.cpp:613)
  hermes              0x107051958  hermes::vm::BoundFunction::create (Callable.cpp:528)
  hermes              0x1070e237c  hermes::vm::functionPrototypeBind (Function.cpp:262)
  hermes              0x10705219c  hermes::vm::NativeFunction::_nativeCall (Callable.h:507)
  hermes              0x10705e924  hermes::vm::Interpreter::handleCallSlowPath (Interpreter.cpp:274)
  hermes              0x107060114  hermes::vm::Interpreter::interpretFunction<T> (Interpreter.cpp:1614)
  hermes              0x10705f924  hermes::vm::Runtime::interpretFunctionImpl (Interpreter.cpp:811)
  hermes              0x107052284  hermes::vm::JSFunction::_callImpl (Callable.cpp:1110)
  hermes              0x107051284  hermes::vm::Callable::call (Callable.h:253)
  hermes              0x107051284  hermes::vm::Callable::executeCall (Callable.cpp:346)
...

EXC_BAD_ACCESS: Exception 1, Code 1, Subcode 5756093448 >
KERN_INVALID_ADDRESS at 0x157170408.
  hermes              0x106ab981c  hermes::vm::GCScope::_newChunkAndPHV (HandleRootOwner.cpp)
  hermes              0x106acf054  hermes::vm::GCScope::newPinnedHermesValue (HandleRootOwner.h:463)
  hermes              0x106acf054  hermes::vm::HandleRootOwner::newPinnedHermesValue (HandleRootOwner-inline.h:97)
  hermes              0x106acf054  hermes::vm::HandleRootOwner::newPinnedHermesValue (HandleRootOwner-inline.h:103)
  hermes              0x106acf054  hermes::vm::HandleBase::HandleBase (Handle-inline.h:37)
  hermes              0x106acf054  hermes::vm::Handle<T>::Handle (Handle.h:317)
  hermes              0x106acf054  hermes::vm::MutableHandle<T>::MutableHandle (Handle.h:450)
  hermes              0x106acf054  hermes::vm::MutableHandle<T>::MutableHandle (Handle.h:450)
  hermes              0x106acf054  hermes::vm::JSObject::getNamedDescriptorUnsafe (JSObject.cpp:919)
  hermes              0x106acf054  hermes::vm::GCScope::newPinnedHermesValue (HandleRootOwner.h:463)
  hermes              0x106acf054  hermes::vm::HandleRootOwner::newPinnedHermesValue (HandleRootOwner-inline.h:97)
  hermes              0x106acf054  hermes::vm::HandleRootOwner::newPinnedHermesValue (HandleRootOwner-inline.h:103)
  hermes              0x106acf054  hermes::vm::HandleBase::HandleBase (Handle-inline.h:37)
  hermes              0x106acf054  hermes::vm::Handle<T>::Handle (Handle.h:317)
  hermes              0x106acf054  hermes::vm::MutableHandle<T>::MutableHandle (Handle.h:450)
  hermes              0x106acf054  hermes::vm::MutableHandle<T>::MutableHandle (Handle.h:450)
  hermes              0x106acf054  hermes::vm::JSObject::getNamedDescriptorUnsafe (JSObject.cpp:919)
  hermes              0x106acf5c4  hermes::vm::JSObject::getNamedDescriptorUnsafe (JSObject.h:1921)
  hermes              0x106acf5c4  hermes::vm::JSObject::getNamedWithReceiver_RJS (JSObject.cpp:1049)
  hermes              0x106ac13f4  hermes::vm::JSObject::getNamed_RJS (JSObject.h:1931)
  hermes              0x106ac13f4  hermes::vm::Interpreter::interpretFunction<T> (Interpreter.cpp:2349)
  hermes              0x106abf924  hermes::vm::Runtime::interpretFunctionImpl (Interpreter.cpp:811)
  hermes              0x106ab2284  hermes::vm::JSFunction::_callImpl (Callable.cpp:1110)
  hermes              0x106ab0a74  hermes::vm::Callable::call (Callable.h:253)
  hermes              0x106ab0a74  hermes::vm::Callable::executeCall0 (Callable.cpp:211)
  hermes              0x106aef0d8  hermes::vm::Runtime::drainJobs (Runtime.cpp:1868)
...

[CMonjo]

Same issue here

[renatomserra]

Also having this issue on 79.6, havent been able to pin a root cause

[matinzd]

I am also seeing hermes vm crashes on 0.79 right now and it has been ongoing for a while.

I am still not sure what's going on. I will keep you all posted.

/cc @koreus7

[simonadenic]

Same issue here. Never reproduced this locally, but happens in production after upgrade to 0.79.6 (newArch = false) Based on Sentry logs, this issue happens durign startup.