I am using Crashlytics for Unity and everything seems to work, but the issues that are getting reported are pretty 'light'.
For example:
How can I get a stack trace for this exception? Do I have to enable some features? This happens for the iOS application.
Related
I'm getting the infamous Maximum Stack Call Size Exceeded error in Expo app.
I understand that it's caused by code that keeps calling itself, creating an infinite loop.
Does Expo or React Native provide more information about where this error is? I've already been through my code and didn't find anything. Something a bit more specific would be helpful in narrowing down the issue.
What's evn more interesting in this case is that I only get the error in the Expo Go app. When I run the app in Android Emulator, I don't get the error and the app works fine.
Any suggestions?
I found the culprit and it's totally unexpected.
I develop web front-end in React and mobile in React Native. One of the primary reasons is code sharing.
I have a file that contains all the action types I use in managing the state of my app. Technically not but kind of an enum file. They look like this:
export const SET_IS_AUTHENTICATED = 'SET_IS_AUTHENTICATED';
export const SET_USER_INFO = 'SET_USER_INFO';
In this file, I have exactly 486 action types and this is exactly what was creating the error.
I don't need all of these action types in my mobile app but I'd decided to keep things consistent and I thought this was totally harmless so I've been sharing this enum file in all my React and React Native apps.
Here are two interesting observations:
I just started developing with Expo. Prior to that I was using straight React Native -- created through React Native CLI and I NEVER got any errors for using this file.
Even more interesting is that the Android Emulator does NOT throw any errors in the same project. Only the Expo Go app throws this error.
This may even be by design and not necessarily an undesired side effect of the Expo Go app. Not sure. I'd love to know if others have had similar experiences with the Expo Go app.
This is probably not helpful, but when I upgraded from expo sdk 41 to 43 then I started getting this error. I made no code changes besides the upgrade and now when my app loads I get the error Unhandled promise rejection, [RangeError: Maximum call stack size exceeded.]. I get the error on expo go on both platforms
Despite the app running perfectly in test builds, when I publish the app or put in in production mode the app builds once that takes a while, then several times within short succession as seen below:
After it stops I then receive the errors:
"Module AppRegistry is not a registered callable module (calling
runApplication)"
and
"undefined is not a function (evaluating
'babelHelpers.objectDestructuringEmpty(d.actions)')"
I have looked up this issue and found that those 2 error messages tend to be vague "catch-all" errors, however none of the posts I found had the rapid build issue I have, so that may a key part to solving this. I have tried restarting the app several times, npm install-ing, updating react and expo to their latest versions, and other small non-code related fixes however none have worked.
Here is a link to my repo: https://github.com/tc1240/AT-Assist. If anyone has had this or can take a look at my code any help is appreciated. Thank you,
Also this is my first question asked on stack so I apologize in advance if my question does not follow some of the guidelines.
I've been experiencing this lately, since I tried publishing for Android and iOS.
I'm currently unable to build additional projects in Expo other than the one I'm working on, so I can't test your project, but:
Can you add the android.package key in your app.json file and try running again? Restoring this back into my project seemed to fix the issue for me.
Can you help us please with these great tools integration.
Our React Native iOS project has been using Crashlytics for several months and it works well in case of native crashes but in case of JS exceptions it required some customization of react-native logging (this Medium articles helped a lot to reach as verbose JS output as possible). In the end we didn't have as good JS errors output as we would like to have.
So we decided to integrate Sentry as well.
It was done successfully, but it seems that Sentry outpaces Crashlytics catching crashes before it: we can see crashes in Sentry dashboard but no in Crashlytics' one.
My question is the next: is it possible to integrate both Crashlytics and Sentry for both case - native crashes AND JS exceptions?
Thank you in advance.
UPD 06.03.2019
Finally, we've come to the usage of only Sentry because of the next reasons:
first of all, it doesn't require any special code for the JS events & errors well-formated output, whereas Crashlytics does;
second, it doesn't require any manipulation with dSym files released (and probably encrypted) via Testflight;
third, it also catches native crashes and provides a verbose output as well.
Sentry has support to React Native which includes the JS and Native errors (both iOS and Android).
I'm totally biased as I work for Sentry but it seems to me, based on your requirements and the two options you listed, Sentry is the one which has the support you need.
Mike from Fabric here. On iOS, only one uncaught exception handler can be safely installed and there will be conflicts, like you're seeing if multiple handlers are installed.
I am facing an issue with iOS 9. My app crashes randomly with EXC_BAD_ACCESS at random location. I tried using the debugger and putting breakpoints to check for any errors.Also tried with exception breakpoints but to no help. My app runs fine on iOS 8.4 and below without any error.
I tried enabling Zombie Objects.On enabling them the App does not crashes till it is connected with the computer for debugging. As soon as the cable is disconnected the app starts crashing.
Also while debugging with Zombie Object with or without breakpoints I don't get any crashes or exception or any log on the console.
If anymore information is required please revert back .
There is a bunch of questions like this one and no general answer since the problem is that it can be caused by numerous reasons. I believe that in my case it was a bug because it has happened on random places. Luckily for me to clean a project has helped me.
So hit Shift+CMD+K and believe.
I've installed Testflight (1.2 B3) as stated in the documentation. Builds are uploading and updating fine. I can see sessions (mostly anonymous :/), I receive the logs (TFLog) - but I do not receive any crash reports. I even introduced a crash-on-event (a method not found thing) - but theres is nothing on Testflight about it.
Provisioning is via a developer profile which embeds several devices.
The problem occurs on iOS6 and iOS5 / iPhone5 and iPad3. The is being build against iOS6.
Any ideas?
UPDATE
I've tested several other frameworks and ways to receive crash reports. Nothing worked so I suspect something in my code (obviously). Are there any other switches that XCode 4.5.1 might have enabled and that way disable any error reporting during a "production environment" like setup?
UPDATE 2
As of now we're using Testflight only for distribution of beta versions and switched to Crashlytics for crash reporting. It's a bit more streamlined and fetches most crashes.
I also do not get any crash reports via TestFlight. This is what the TestFlight people told me:
Our team is currently looking into an issue associated with auto
versioning of the app when uploaded and SDK data not reporting
properly. Looking at the URL you provided it looks like the build
version is not changing before uploading the app to TestFlight and our
auto versioning implementation is causing an issue with general SDK
data reporting.
I will share this with our team and we will contact you when we have
an update available.
I tried to update the build version to avoid auto-versioning, but it did not help me. But maybe this issue is hitting someone else.
Testflight did not satisfy our needs to log crashes. That is why we skipped to Crashlytics (as I said in the original post). The issues with Testflight seem not to be resolved. We still do use it for distribution, that is what it's good at.