App crashes on start when loaded from EAS Update, after upgrading to SDK 49

Expo Application Services (EAS)
1

Hi, I am running a managed app which I just upgraded to SDK 49.
eas-cli/3.17.1 darwin-arm64 node-v18.17.0

My app, even tough running great locally, crashes on start when I open it from an EAS update usin the Expo Go app.
I have tried investigating it for 3 days now and couldn’t fix it.

I used XCode ‘console’ app to get the error logged when the Expo Go app is crashing.
Here are the 3 error logs I found there:

  • Expo Go RangeError: Maximum call stack size exceeded (native stack depth), js engine: hermes
  • Expo Go Invariant Violation: “main” has not been registered. This can happen if:
    • Metro (the local dev server) is run from the wrong folder. Check if Metro is running, stop it and restart it in the current project.
    • A module failed to load due to an error and AppRegistry.registerComponent wasn’t called., js engine: hermes
  • Expo Go NSInvalidArgumentException: -[EXReactAppExceptionHandler handleFatalJSExceptionWithMessage:stack:exceptionId:extraDataAsJSON:]: unrecognized selector sent to instance 0x281fa8380

After Googling these I realized that the one I should focus on is the first one (the ‘RangeError’) since the others are just a result of it, and that the issue is probably caused by one of my dependencies failing for some reason.

Looking into that made me suspect ‘react-native-reanimated’ (because of that Github issue), so I tried downgrading back to 2.14.4 which is the previous version I used, and when I ran that locally the app crashed with the error:

TypeError: _ReanimatedModule.default.createNode is not a function (it is undefined), js engine: hermes

Followed by the same: “main” has not been registered error, so I thought it was worth mentioning.

Then I used npx expo prebuild -p ios and ran that using XCode, which worked fine at first,
but after a few runs suddenly crashed with this:

ReanimatedError: Maximum call stack size exceeded (native stack depth). , js engine: reanimated

I also tried switching the jsEngine to JSC but all it did was giving me even less usefull error logs.

I already thought I figured it out twice now but then a day later I make a new EAS update and it crashes again, so I couldn’t even get consistency there.

I am really frustrated… would appreciate your help so much :heavy_heart_exclamation:

2

I have tried again & again to make a minimal reproducible example but failed.
The issue is very inconsistent…
I have however managed to determine with some certainty that if I comment out all references using react-native-reanimated from my code the issue is resolved.
So I’m sure the problem lies within reanimated. It’s just so strange that it isn’t consistent.

I didn’t include the full stack trace in the original post, so I’ll add it here:

08-04 18:47:31.324 13613 29106 E ReactNativeJS: RangeError: Maximum call stack size exceeded (native stack depth), js engine: hermes
08-04 18:47:31.326 13613 29106 I ReactNativeJS: Running "main
08-04 18:47:31.327 13613 29106 E ReactNativeJS: Invariant Violation: "main" has not been registered. This can happen if:
08-04 18:47:31.327 13613 29106 E ReactNativeJS: * Metro (the local dev server) is run from the wrong folder. Check if Metro is running, stop it and restart it in the current project.
08-04 18:47:31.327 13613 29106 E ReactNativeJS: * A module failed to load due to an error and `AppRegistry.registerComponent` wasn't called., js engine: hermes
08-04 18:47:31.335 13613 29107 W System.err: java.lang.reflect.InvocationTargetException
08-04 18:47:31.335 13613 29107 W System.err: at java.lang.reflect.Method.invoke(Native Method)
08-04 18:47:31.335 13613 29107 W System.err: at abi49_0_0.com.facebook.react.bridge.DefaultJSExceptionHandler.handleException(DefaultJSExceptionHandler.java:70)
08-04 18:47:31.335 13613 29107 W System.err: at abi49_0_0.com.facebook.react.devsupport.DisabledDevSupportManager.handleException(DisabledDevSupportManager.java:3)
08-04 18:47:31.335 13613 29107 W System.err: at abi49_0_0.com.facebook.react.bridge.CatalystInstanceImpl.onNativeException(CatalystInstanceImpl.java:3)
08-04 18:47:31.335 13613 29107 W System.err: at abi49_0_0.com.facebook.react.bridge.CatalystInstanceImpl.access$1100(CatalystInstanceImpl.java:1)
08-04 18:47:31.335 13613 29107 W System.err: at abi49_0_0.com.facebook.react.bridge.CatalystInstanceImpl$NativeExceptionHandler.handleException(CatalystInstanceImpl.java:3)
08-04 18:47:31.335 13613 29107 W System.err: at abi49_0_0.com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:8)
08-04 18:47:31.335 13613 29107 W System.err: at android.os.Looper.loop(Looper.java:214)
08-04 18:47:31.335 13613 29107 W System.err: at abi49_0_0.com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:38)
08-04 18:47:31.335 13613 29107 W System.err: at java.lang.Thread.run(Thread.java:764)
08-04 18:47:31.336 13613 29107 W System.err: Caused by: com.facebook.react.common.JavascriptException: RangeError: Maximum call stack size exceeded (native stack depth), js engine: hermes, stack:

I also noticed another error log that may be related, it comes before the one I included above.

08-04 18:47:30.761 13613 29099 E UpdatesUtils: Failed to parse date string on first try: 2023-08-04T15:37:15.114Z
08-04 18:47:30.761 13613 29099 E UpdatesUtils: java.text.ParseException: Unparseable date: "2023-08-04T15:37:15.114Z"
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at java.text.DateFormat.parse(DateFormat.java:362)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at expo.modules.updates.UpdatesUtils.parseDateString(UpdatesUtils.kt:52)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at expo.modules.updates.manifest.NewUpdateManifest$Companion.fromNewManifest(NewUpdateManifest.kt:37)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at expo.modules.updates.manifest.ManifestFactory.getManifest(ManifestFactory.kt:60)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at expo.modules.updates.loader.FileDownloader$Companion.checkCodeSigningAndCreateManifest(FileDownloader.kt:9)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at expo.modules.updates.loader.FileDownloader$Companion.access$checkCodeSigningAndCreateManifest(FileDownloader.kt:1)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at expo.modules.updates.loader.FileDownloader$parseManifest$1.onCompleted(FileDownloader.kt:40)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at expo.modules.updates.loader.LegacySignatureUtilsKt$fetchExpoPublicKeyAndVerifyPublicRSASignature$1.onResponse(LegacySignatureUtils.kt:32)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at expo.modules.updates.loader.FileDownloader$downloadData$1.onResponse(FileDownloader.kt:13)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:61)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
08-04 18:47:30.761 13613 29099 E UpdatesUtils: at java.lang.Thread.run(Thread.java:764)

If it is relevant in any way maybe it’ll explain the inconsistency I’ve described where the same code may work in a certain EAS update yet crash when uploaded again the next day, but IDK, just a crazy theory maybe :man_shrugging:

P.S: Building an apk of the app works well with no issues, the crashes only happen when opening through Expo Go.
And, it crashes on iOS, while just hanging on the ‘New update available, downloading…’ step forever in Android.

Any leads or guidance at all? would really appreciate some help :pray:

3

We are also having the same issues after upgrading to SDK 49, it only happens if there is a eas-update available:

Failed to parse date string on first try: 2023-10-18T22:00:04.601Z

java.text.ParseException: Unparseable date: "2023-10-18T22:00:04.601Z"
at java.text.DateFormat.parse(DateFormat.java:389)
at expo.modules.updates.UpdatesUtils.parseDateString(UpdatesUtils.kt:282)
at expo.modules.updates.manifest.NewUpdateManifest$Companion.fromNewManifest(NewUpdateManifest.kt:102)
at expo.modules.updates.manifest.ManifestFactory.getManifest(ManifestFactory.kt:23)
at expo.modules.updates.loader.FileDownloader$Companion.checkCodeSigningAndCreateManifest(FileDownloader.kt:692)
at expo.modules.updates.loader.FileDownloader$Companion.access$checkCodeSigningAndCreateManifest(FileDownloader.kt:627)
at expo.modules.updates.loader.FileDownloader.parseManifest(FileDownloader.kt:494)
at expo.modules.updates.loader.FileDownloader.parseMultipartRemoteUpdateResponse(FileDownloader.kt:330)
at expo.modules.updates.loader.FileDownloader.parseRemoteUpdateResponse$expo_updates_release(FileDownloader.kt:149)
at expo.modules.updates.loader.FileDownloader$downloadRemoteUpdate$1.onResponse(FileDownloader.kt:548)
at expo.modules.updates.loader.FileDownloader$downloadData$1.onResponse(FileDownloader.kt:622)
at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
at java.lang.Thread.run(Thread.java:1012)
4

Hi, we’ve looked into this and suspect these crashes are due to the differences between Android versions and how they parse date format strings.

Specifically, some releases of Android can parse “Z” as a time zone in strings, and some can parse “X”. The logic for whether to use “Z” or “X” changed in the latest release. We’re looking into what the right fix is. Thank you for your patience.

5

Hi, we published a new version, expo-updates@0.18.17 today with a fix that handles date string parsing more robustly across all versions of Android. The date parsing change is the sole change between 0.18.16 and 0.18.17.

1 Like
6

Hi, thanks so much for working on a fix!

I haven’t tested it out yet, but I have experienced the issue on iOS too so I was a bit concerned when you mentioned you guys believe it’s an android related problem :sweat_smile:

7

The fix affects only Android, specifically:

java.text.ParseException: Unparseable date: "2023-10-18T22:00:04.601Z"
at java.text.DateFormat.parse(DateFormat.java:389)
at expo.modules.updates.UpdatesUtils.parseDateString(UpdatesUtils.kt:282)

The error in the original post about RangeError: Maximum call stack size exceeded (native stack depth), js engine: hermes and Invariant Violation: “main” has not been registered. look like they could be due to application code. If they are reproduceable with the new project template and are shown to be issues in the expo-updates library we can take a look at it. Otherwise it looks like the issue is with the app’s own JS code.