Our Expo app is crashing in production with all exceptions

Our Expo app is crashing and we don’t know how to debug.

We have an iOS app running Expo 45.0.6. Over the past few weeks we noticed our Sentry exceptions were way down (we use sentry-expo). Yesterday we suspected an issue with Sentry so we introduced an exception into our production app. Tapping a button triggered the exception and our app hard crashed. No sentry issue was reported. But when we re-opened the app the exception got sent to Sentry. This explains why Sentry has been telling us a lot less lately. But we can’t figure out why all exceptions in our React Native code are hard-crashing the app.

Here is what we’ve tried:

  • We reviewed all the details in Using Sentry - Expo Documentation and made a couple changes to ensure we are fully reflecting these instructions. The app still crashes.
  • We tried upgrading to:
"@sentry/react-native": "4.6.1",
"sentry-expo": "5.0.3",

The app still crashes. Notably, expo doctor says those versions are incompatible so we’ve downgraded them back. Notably, we cannot upgrade to Expo 46 because a key library we use (Agora) doesn’t support Expo 46 yet. We are back on:

"@sentry/react-native": "3.1.1",
"sentry-expo": "4.2.0",
  • We got our TestFlight build to crash so we got the TestFlight crash report and stack trace, but we can’t find anything useful in there. It’s hard to make sense of.
  • We try this in our dev app and it works. We’re not using Expo Go, we’ve built our own dev binary. And when we throw exceptions in this Sentry catches them and the app does not crash. It’s only when we build a full binary that things crash.

We are at a loss… Is this an issue with Sentry or Expo? Something incompatible between the two? Or nothing to do with either and some other code change we made in the past few weeks? We’re not sure how to proceed with debugging this.

Looking at your crash log, one line stands out in particular: 0x10021a74c -[RNSentry captureEnvelope:options:resolve:rejecter:] + 292 (RNSentry.m:276). The surrounding stack frames show that this method is being called from React Native’s bridge and the reason for the crash is that this selector doesn’t exist. That is, there is no -[RNSentry captureEnvelope:options:resolve:rejecter:] method in your native code.

Your yarn.lock file shows that you have two copies of the Sentry module:

  version "3.1.1"
  version "3.4.3"

You should dedupe these packages (more on this at the end), but I don’t think this is the cause of your problem.

Both the RNSentry.m file in v3.1.1 and the RNSentry.m file in v3.4.3 define -[RNSentry captureEnvelope:resolve:rejecter:], which is the wrong selector. The difference is subtle. Your app is crashing trying to call:
-[RNSentry captureEnvelope:options:resolve:rejecter:]

Both v3.1.1 and v3.4.3 define:
-[RNSentry captureEnvelope:resolve:rejecter:]

The options parameter was added in 396f4f7b5, which was first published in v4.4.0.

I suspect that you may have some outdated JavaScript or perhaps a CocoaPods header somewhere from when you tried to upgrade to "@sentry/react-native": "4.6.1". Something is trying to call the newer version of the method with the options parameter, while your app actually has the older code without it. Hopefully this gives you some pointers on where to look next.

Deduping dependencies in your yarn.lock file. There are two ways to do this. One is to change your package.json to depend on "@sentry/react-native": "^3.1.1" with the semver carat and run yarn again. Verify by reading the lockfile that there’s only one entry for "@sentry/react-native" and that it’s version 3.4.3.

The second way is to delete the second lockfile entry and merge it into the first one so that Yarn resolves both dependency specifiers to v3.1.1 :

"@sentry/react-native@3.1.1", "@sentry/react-native@^3.1.1":
  version "3.1.1"
  resolved "https://registry.yarnpkg.com/@sentry/react-native/-/react-native-3.1.1.tgz#4edd555ff5a9eda292d067314282b2c1cb519512"
  integrity sha512-w+KVlZ5pj0irI5vo1KhdPbr7EFT7bDeAENfckwYE+ogZWsEitokxvkPy7eqKZnbyQf3stlYACU96tRiwRLqiaA==

Hi. We have an error similar to yours. Did you manage to solve yours? We would very grateful if you could elaborate on the solution.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.