Crashlytics doesn't catch SIGSEGV in Android - crashlytics

Today we found that Crashlytics don't catch SIGSEGV crashes, but google play console does. We were quite surprised to see many of such crashes in play console.
We want to have our crash reporting in one place. Can we catch SIGSEGV crashes with crashlytics?

The standard Android Crashlytics SDK catches Java crashes. Since SIGSEGV is a native crash you'll also need to include the Crashlytics NDK SDK, whether the SIGSEGV originates in an app's native libraries or third-party libraries. Check out https://fabric.io/downloads/gradle (with the NDK toggle switch on) for setup instructions.

Related

Firebase Crash Reporting automatically generates reports for fatal errors in android phone but not for iPhones?

I have setup firebase in my react native app.
But currently exceptions are not handled means not added any crashlytics logs or recorded errors
But for android app I am getting crashes in firebase but not for IOS.
Can someone explain this in detail?
Crashlytics may only be able to upload the data once the app starts again. Did you restart the app?
This can happen if you are testing while the Xcode debugger is attached.
Check this document, it explains how to test this in iOS.
If that doesn't work, enable debug logging and check if something is causing issues. For this:
After enabling debug mode, run the app.
Then hit "stop" in Xcode.
Run the app in the device and crash it
Run the app again from Xcode
Collect the output from Xcode

Can I use Crashlytics only for C++ crash reporting?

I have an app with Java and C++ code. Is it possible for me to only use Crashlytics to catch C++ crashes and not Java crashes? I tried using
Fabric.with(this, new CrashlyticsNdk());
but that gives me an error about Crashlytics needing to be initialized.
Edit: I don't mind using Crashlytics for Java crashes, but management is hard to convince. As far as they're concerned, our existing crash reporting solution works for Java crashes (but it doesn't work too well for native crashes) so the 'ideal' solution is to use Crashlytics only for C++ crashes.
Mike from Firebase here. No, the NDK SDK needs to have Crashlytics present in order to report everything correctly.

Exception while running xamarin ios app on devices only. The App runs on simulator perfectly

I am using native ios framework in xamarin ios application. However i am getting an error while runtime. It throws below exception on device at runtime but it works smoothly on simulators.
Name: NSInvalidArgumentException Reason:NSDate consoleOutputTimestamp.
The reason might be, I was using a third-party NSDate category in my naive iOS framework. When I removed the whole NSDate third-party library.
I was able to build it, however it throws a different exception this time. The exception is as below :
Name:NSInvalidArgumentException Reason:UIViewController setIsFullScreen:
Objective-C exception thrown. Name: NSInvalidArgumentException Reason: -[UIViewController setIsFullScreen:]: unrecognized selector sent to instance 0x145b3fd0
Means every time I am making changes in native framework, after building it at runtime it throws an exception on devices only.
However the native iOS framework runs on devices in native iOS app smoothly.
However I am getting exception when I build it in Xamarin and runs it in Xamarin App. I have made changes related to architecture in Xamarin while building and in sample app as well but that didn't help. Do i need to make any changes in Xamarin project ?
I am using latest version of visual studio. The app stops at launch time and throws exception.
Please share if you have any idea about this. Thanks in advance.

app runs within Xcode project, but not after built

I have a Xcode project, my small mac app runs all successfully within Xcode test run after compile, but by running the debug or release build by itself, the app become unresponsive after start running. No error or warning during building.
I don't know where to look to start troubleshooting this, so totally stuck. How do you start investigating for the issue like this?
I would start by setting an exception breakpoint for your project in Xcode. Xcode will pause your app when it throws an exception. Exceptions are thrown when runtime errors occur in your code. Setting an exception breakpoint can help you find the problem in your code.
If no exception breakpoints fire when you debug the app in Xcode, you will need to update your question with more information about your app. Is your app a GUI app or a command-line app? Does your app do anything special at startup, such as load files?

Logging runtime crashes in mono on OS X

I'd like to know about any and all crashes of my app 'in the wild'. We can capture managed exceptions easily enough using AppDomain.CurrentDomain.UnhandledException.
Occasionally we get crashes in unmanaged code (either through our own interactions with native libraries, or sometimes from misusing monomac or problems with monomac itself). I would like to know when these happen, as well.
I have bound the plcrashreporter framework and added it to my app. I have read the discussion around using crash reporters with Xamarin.iOS applications and implemented the workaround.
So far, so good - I can use the crash reporter and my app runs fine. However, I seem to be limited in what signals actually get caught.
For example, SIGILL and SIGABRT both get trapped by the crash reporter. A crash report is written to disk and can be read back next time the app starts up.
However, SIGSEGV and SIGBUS don't get caught. Instead, I get a stack trace written to the console along with:
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
So it seems that the situation on Mac is not exactly the same as the situation on iOS. The workaround allows the crash reporter to run, but Mono doesn't seem to be raising a SIGABRT when it get a SIGSEGV from unmanaged code.
Any ideas?
The workaround for removing and reassigning the SIGSEGV and SIGBUS handlers is only required for the application to run with the debugger attached
Since we are only interested in live errors, we can surround the code to enable PLCrashReporter with an #IF DEBUG.