We use Crashlytics for reporting crashes faced by our Android app users. A lot of our code is native (c++), hence a lot of crashes are in native code. However most (if not all) of them end up getting grouped under "abort_message.cpp line 77". And this is the top part of the stacktrace for all kind of different crashes -
I have tested by making different kinds of crashes in different files, like throw std::runtime_error("Testing crash"), throw std::logic_error("Testing crash2"), but all of them end up having the top few frames same (as the image above).
Now since the top frame of crash stack is abort_message.cpp line 77 for all of them, they get grouped under same head.
Grouping dissimilar crashes in same group, makes it hard to prioritize and target crash fixes. So is there anyway we can fix this? Or workaround this?
NOTE: We are uploading native symbols to crashlytics alright, and our stack traces are quite detailed.
Another thing that bothers me is that different type of crashes are all reported as SIGABRT.
Fabric/Firebaser here -
This looks to be a C++ exception that Crashlytics is not unwinding very well - this is an aspect of NDK integration with Crashlytics that we're looking to improve for the future. When a C++ exception is thrown, the signal that is raised by an uncaught C++ exception is processed rather than handling the exception itself, resulting in these first few frames of the stacktrace being the same and grouping together different issues as a result.
It should still have the relevant crash information, so the frames below should be different, but the blame frame will be that abort_message frame.
Thanks for the report - it's definitely something we're looking into making better soon.
I also have the same complaint.
Is there a workaround?
Just received a spike alert from Firebase from having the same error spiking, and they were all unrelated crashes (from throw exceptions incorrectly grouped as the same)
Related
I had Firebase Crashlytics installed in my Android app, and the reporting is operational.
However, I found that some issues are very similar:
And it'd be helpful if I could treat them as the same issue when debugging or closing.
Is there any chances I can merge them into one?
It is not possible to merge these crashes. Crashlytics will group the issues based on the frame being blamed. In this case, even though they look similar, the frame is under a different line number.
You could file a feature request for this behavior.
Some version information first: I am talking about the module com.crashlytics.sdk.android:crashlytics:2.8.0 and the Gradle plugin io.fabric.tools:gradle:1.25.1.
I was excited to learn that Crashlytics can also log caught exceptions as nonfatal issues. But this doesn't seem to work the way I hoped it would.
Firstly, logException doesn't seem to trigger anything until the app is restarted after a crash. This renders the feature of logging nonfatal issues (app caught the exception and kept on running!) pretty useless.
Secondly, if there are two or more exceptions logged via logException before a crash, the last one wins and the others vanish into the eternal void. This is what I have observed during my experiments.
So what am I missing? Is there a way to tell Crashlytics that a logged exception should be sent out right away? Is this the way Crashlytics is intended to work, or is the implementation flawed? As it stands now, log und logException aren't of much use.
You're not missing anything, Crashlytics wasn't really designed with that use case in mind, which is related more to analytics than to crash reporting. You could instead use Answers APIs, also part of the Fabric platform. Note however, that there is no guarantee the logs will be sent right away, there is some delay before they appear in the dashboard.
I'm making a research about if there is any problem in compiling native code for Android 5 or superior using NDK 9 but couldn't yet find any answer.
I already made a long search in source.android.com, this page was the closer I could get to answering but it is not clear yet...
I'm asking this because I'm having a SIGSEGV problem in a native code written in C to be put in my Android app. Before Android 5, the code run smoothly but in every device using android 5 or superior gives this error ocasionally (sometimes the code runs without error).
For the NDK version, it should be fine. It's an older vintage but should still
build your code correctly. I'd try and update as soon as you can though, just to
keep current. I don't think this would be the cause of the crash.
Android 5 introduced the Android Runtime (ART) by default. Prior to this
the VM used was Dalvik. I found that the JNI layer in Android 5 was a
lot stricter. In the old Dalvik world you could often get away with, for
example, sharing a JNIEnv pointer between JNI calls. In ART this is not
possible and will always crash. Just to be clear, in Dalvik it should not work
either but you could get away with it, so the mistake went undetected.
Another thing to watch out for is creating large local variables, such as
arrays, on the stack. In Dalvik each thread had 2 stacks, one for JNI code and
one for Java, but in ART the stack is shared between native and Java. So the
JNI code may be running out of stack and crashing. These kinds of crashes can
be very difficult to track down. Code inspection looking for local
(non-malloc'd) arrays has been the way I've found some in the past.
Is there a good stack trace from logcat? Usually you can debug a SIGSEGV by
building in debug and passing the stack trace through ndk-stack.
If you're lucky it gives you the line where your code crashes.
I've been getting some crashes in my app out in the field an one crash that I received is very interesting in nature. For one of the crashes happening the service I am using is reporting a SIGSEGV SEGV_MAPERR in libwebviewchromium.so and the only information coming back is the address 0x00000000fbadbeef. It seems kind of ironic that not only the address is readable, but it also so consistent.
I'm unable to create the crash locally so I don't have a full trace, but I was curious if there is a know issue or reason for the 0xfbadbeef address in libwebviewchromium and if ther is a fix for it or way to reduce it from happening.
From the Chromium WebKit sources — see the comment just above the macro definition — , this is their code for "known, unrecoverable errors like out-of-memory".
Obviously with code, errors can occur anywhere. So without having try/catch blocks all over the place (which as I understand it is major overhead) how do I allow errors to bubble up to the application level and then handle them there? Or at the very least, record the error somehow for troubleshooting? I found information on an product called ACRA, but the setup instructions are geared for Eclipse projects. I am using Mono for Android in Visual Studio 2010.
That's a bit of an "It depends" question.
The appropriate handling of an errors is going to depend on what the recovery strategy needs to be, how much information you want the user to see etc.
I wouldn't worry how many Try/Catch blocks you use - just use them wherever you need to handle an error that gets thrown - if they're everywhere, your strategy is probably wrong.
It terms of logging and later interrogation, you can log caught errors using the Android.Util.Log class.
These can be interrogated (provided you're debugging on your own device) using Logcat.
There's some more info on logging and Logcat here.
Found this project that writes crash info to google docs. Android Crasher