expo: [SDK 49][reanimated] makeShareableCloneRecursive Call Stack Size Exceeded

Summary

After upgrading from expo@49.0.0-beta.2 to expo@49.0.0-beta.5, and now to expo@49.0.0, we started seeing a crash on launch on the Android Release build variant. Debug does not have this issue.

Using Android Studio, we get this stacktrace:

Screenshot 2023-07-05 at 3 34 11 PM

The function makeShareableCloneRecursive comes from https://github.com/software-mansion/react-native-reanimated/blob/main/src/reanimated2/shareables.ts#L88 and the bug should have been fixed in react-native-reanimated@3.2.0 via https://github.com/software-mansion/react-native-reanimated/pull/4475. I wonder if there was a mistake in this commit https://github.com/expo/expo/pull/23262/files#diff-3511e87e69ca6f237ac5968ae3465472df02c91b8062d50363853840095e6736 that might have led to this regression?

Managed or bare workflow?

bare

What platform(s) does this occur on?

Android

Package versions

{
    "expo": "49.0.0-beta.5",
    "expo-barcode-scanner": "~12.5.3",
    "expo-camera": "~13.4.2",
    "expo-clipboard": "~4.3.0",
    "expo-constants": "~14.4.2",
    "expo-dev-client": "~2.4.3",
    "expo-dev-menu": "~3.1.6",
    "expo-file-system": "~15.4.2",
    "expo-image": "~1.3.1",
    "expo-navigation-bar": "~2.3.0",
    "expo-print": "~12.4.2",
    "expo-screen-orientation": "~6.0.2",
    "expo-sharing": "~11.5.0",
    "expo-splash-screen": "~0.20.3",
    "expo-updates": "~0.18.8",
    "react-native-reanimated": "~3.3.0",
}

Environment

expo-env-info 1.0.5 environment info:
    System:
      OS: macOS 13.4.1
      Shell: 5.9 - /bin/zsh
    Binaries:
      Node: 16.15.0 - ~/.asdf/installs/nodejs/16.15.0/bin/node
      Yarn: 1.22.19 - ~/.asdf/installs/nodejs/16.15.0/bin/yarn
      npm: 8.5.5 - ~/.asdf/plugins/nodejs/shims/npm
      Watchman: 2023.06.26.00 - /opt/homebrew/bin/watchman
    Managers:
      CocoaPods: 1.12.1 - /Users/thespacemanatee/.asdf/shims/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
      Android SDK:
        API Levels: 23, 26, 29, 30, 31, 33
        Build Tools: 26.0.3, 29.0.2, 30.0.3, 31.0.0, 33.0.0, 33.0.2, 34.0.0
        System Images: android-24 | Google APIs ARM 64 v8a, android-26 | Google APIs ARM 64 v8a, android-26 | Google APIs Intel x86_64 Atom, android-26 | Google Play Intel x86 Atom, android-29 | Google Play ARM 64 v8a, android-33 | Google APIs ARM 64 v8a
    IDEs:
      Xcode: 14.3/14E222b - /usr/bin/xcodebuild
    npmPackages:
      expo: ^49.0.0-beta.5 => 49.0.0-beta.5 
    npmGlobalPackages:
      eas-cli: 3.14.0
    Expo Workflow: bare

Reproducible demo

I could not reproduce this with a fresh project, but there was a similar issue reported software-mansion/react-native-reanimated#4177

I spent hours debugging and I can come up with this pattern:

Starting from beta.2

  1. bumped to beta.3 successfully
  2. bumped to beta.4 successfully
  3. bumped to beta.5 and started getting the crash on app launch of the Release build
  4. downgraded to beta.4 and still got the crash
  5. downgraded to beta.3 and still got the crash
  6. downgraded to beta.2 and no longer get the crash
  7. repeat the whole process from step 1

Stacktrace (if a crash is involved)

com.facebook.react.common.JavascriptException: RangeError: Maximum call stack size exceeded (native stack depth), js engine: hermes, stack:
        makeShareableCloneRecursive@1:688707
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688469
        anonymous@1:688809
        makeShareableCloneRecursive@1:688707
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688469
        anonymous@1:688809
        makeShareableCloneRecursive@1:688707
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688469
        anonymous@1:688809
        makeShareableCloneRecursive@1:688707
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688469
        anonymous@1:688809
        makeShareableCloneRecursive@1:688707
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688469
        anonymous@1:688809
        makeShareableCloneRecursive@1:688707
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688469
        anonymous@1:688809
        makeShareableCloneRecursive@1:688707
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688469
        anonymous@1:688809
        makeShareableCloneRecursive@1:688707
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688469
        anonymous@1:688809
        makeShareableCloneRecursive@1:688707
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        makeShareableCloneRecursive@1:688615
        anonymous@1:694756
        initializeUIRuntime@1:701115
        anonymous@1:686016
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:678957
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:671360
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:670766
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:669690
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:669230
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:667702
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:664648
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:664343
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:663375
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110996
        metroRequire@1:110624
        anonymous@1:117792
        loadModuleImplementation@1:111442
        guardedLoadModule@1:110953
        metroRequire@1:110624
        global@1:110180
        
         at com.facebook.react.modules.core.ExceptionsManagerModule.reportException(ExceptionsManagerModule.java:65)
         at java.lang.reflect.Method.invoke(Native Method)
         at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
         at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
         at com.facebook.jni.NativeRunnable.run(Native Method)
         at android.os.Handler.handleCallback(Handler.java:942)
         at android.os.Handler.dispatchMessage(Handler.java:99)
         at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
         at android.os.Looper.loopOnce(Looper.java:201)
         at android.os.Looper.loop(Looper.java:288)
         at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:228)
         at java.lang.Thread.run(Thread.java:1012)

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 12
  • Comments: 22 (13 by maintainers)

Most upvoted comments

Hi, I had the same issue with expo@49 while using a development build from expo cloud. I’ve upgraded expo to 49.0.9 (before 49.0.5) and also react-native from 0.72.3 to 0.72.4. Then I followed the suggestions from this issue to add environment variables BABEL_ENV and APP_VARIANT so that my eas.json looks like that for an internal development build:

    "development": {
      "distribution": "internal",
      "releaseChannel": "development",
      "env": {
        "ENVIRONMENT": "production",
        "NODE_ENV": "development",
        "BABEL_ENV": "release",
        "APP_VARIANT": "release"
      },
      "node": "16.15.1",
      "ios": {
        "resourceClass": "m-medium"
      }
    },

Now its working. thank you guys.

+8
flodev on Sep 7, 2023

Facing the same issue with expo@49.0.6 + reanimated@3.4.1 using managed workflow.

Expo go and development build works fine, but the standalone app crashes on launch. With Expo SDK 48 everything works fine as well.

Tried this and this, tried disabling new expo envs and so on. Nothing really helps.

+6
R0ixy on Aug 1, 2023

I’m facing same issue:

managed workflow
"expo": "^49.0.9"
"react-native": "0.72.4"
"react-native-reanimated": "3.3.0" I tried with latest as well

It works fine in expo go but when creating builds for Android or IOS the app crashes on launch, If I remove react-native-reanimated then it works as expected.

+3
moygoca1 on Sep 6, 2023

@Kudo it might have been expo after all, after bumping expo dependencies to the latest round of updates, the issue has resolved itself. Will close this next week if it doesn’t reappear again.

EDIT: the issue comes back on a different development machine. Wonder if some process is being cached?

EDIT 2: Clearing ~/.gradle and running ./gradlew clean and Invalidating Caches in Android Studio for good measure works for this machine. Again, will keep this issue up for another week just in case.

+3
thespacemanatee on Jul 11, 2023

https://github.com/software-mansion/react-native-reanimated/issues/4737

+2
thespacemanatee on Jul 16, 2023

I’m running into the exact same issue.

Just to make sure we are doing the “right” thing, should BABEL_ENV be set to release as in the comment above, or should it be set to production? Looking at some code, seems like maybe production would be more suitable, maybe?

Works the same with production and release for me.

+1
bisak on Jan 4, 2024

I can confirm that using latest and greatest versions (react-native@0.72.3 + expo@49.0.3) issue on my end is still a problem.

The release build works fine. Disabling DEV mode on a debug build does not.

+1
RohovDmytro on Jul 13, 2023

it’s still unclear to me how this happens. if there’s any repros, we can help to investigate further. seeing you created https://github.com/software-mansion/react-native-reanimated/issues/4690. hopes reanimated team has any thought for the issue.

+1
Kudo on Jul 9, 2023

if there’s something from #23262, i would say react-native 0.72.1 bump. could you try to downgrade react-native to 0.72.0 and see if that help?

+1
Kudo on Jul 7, 2023
Read more comments on GitHub
← expo: [SDK 49][expo-updates][android] gradle plugin error on build when running on Windows
expo: [SDK 50]: `compilerOptions.baseUrl` causes tamagui to not work once migrating from SDK 49. →