On iOS, in our standalone production build, rendering <Camera/> immediately crashes the app. Tried the following
Doesn’t crash in the expo client on the iOS simulator in dev or production mode
Doesn’t crash in the expo client on my iOS device in dev or production mode
Doesn’t crash in the expo client on the Android simulator in dev mode
Does crash in the standalone production build of our app on my iOS device.
It crashes (completely exiting the app) before anything is logged to Sentry, which makes me think there’s a good chance this is happening on the “native” side. I checked and we’ve granted camera permissions to our app in the iOS settings.
I tried to reproduce it in snack but wasn’t able to import the Camera module, then realized I probably can’t reproduce it with the expo client anyway. I expo publish’d a few times to narrow it down and it seems to happen if we return <Camera/>; in our render function of the screen, like so
import { Camera } from 'expo-camera';
import React, { Component, Fragment } from 'react';
import {
Platform,
} from 'react-native';
export default class CameraScreen extends Component {
// ... [our original code]
render() {
if (Platform.OS === 'ios') {
return <Camera/>; // if we instead return null here, doesn't crash
}
// ... [our original code]
}
}
Thanks @charliecruzan! Do you or @sjchmiela know when we can expect to include the fix in our app? Is it an Expo build server fix, or just a package update we should keep an eye out for on npm?
In the meantime, I reverted my upgrade-to-SDK-34 commit and rebuilt with SDK 33 to get around the problem. That’s been working today, and then I’ll return to 34 with this fix in place.
Hi @wodin for some reason neither Crashlytics nor Testflight seems to be generating crash reports. Very frustrating stuff. I’m using face detector. Here is the code that I am using.
OK, it will be very difficult to track down without a crash report. Do you get a crash report locally that you can manually symbolicate?
Another idea (although it might be a lot of effort): If you can build the app locally on your machine with a custom Expo SDK maybe you can try to use git bisect to find where the problem was introduced. For this you’d need to do something like clone GitHub - expo/react-native: A framework for building native apps with React. and then bisect between a version of the SDK that worked for you and the sdk-34.0.1 tag. This is not something I’ve done before with Expo, but I have used git bisect successfully for other things several times.
Ok, well you might have to wait for one of the Expo devs to have a look next week. It might be a good idea to open a new issue and including the details from your comments on the other bug and also the stack trace.
Unless your Objective-C skills are better than mine
Thank you very much for all of your help. Hopefully this can get resolved quickly. I did however notice that my report looks almost identical to the one that was used to solve this issue, with the exception of line 7 on my own crash report. Any idea as to why this might be?
hmmm…, I see. I think in that case the face detector wasn’t being used at all, so presumably the faceDetectorSettings were empty/missing. The fix was just to put the face detector creation inside try/catch. I am not sure why this doesn’t work around the crash in your case, but anyway, since you want to actually use the face detector the fix would not help you.
Maybe just post your stack trace to that bug then and point out the similarity to the other one, but say that you are in fact trying to use the face detector, unlike the person who posted the other stack trace.
EDIT:
I was going to suggest trying to build camerja to see if that also crashes for you, but it doesn’t seem to have been updated for SDK 34.
