I'm getting a lot of crashes on this in my production application. I have not been able to reproduce it myself, and the crash stack trace does not mention any of my own files. As you can see on the crash overview, I get the same crash many different places.
Is this a bug in the bottom navigation library? Has anyone else experienced this?
Related
Off late I am getting these strange crashes on some of the users devices. As per the stacktrace, the code which crashed wasn't even supposed to be executed.
at <package>.ProfileFragmentKt$navigationItemSelected$drawerListenerForLogout$1$onDrawerClosed$1.onClick$lambda-1(ProfileFragmentKt.java:430)
at <package>.OveralLeaderBoard$$InternalSyntheticLambda$1$02abf2b02b6613054134ac54a51b1d4fe0a610803b5aa4ed543d8bcfe4103eb0$0.onChanged$bridge(OveralLeaderBoard.java:2)
at androidx.lifecycle.LiveData.considerNotify(LiveData.java:133)
at androidx.lifecycle.LiveData.dispatchingValue(LiveData.java:151)
at androidx.lifecycle.LiveData.setValue(LiveData.java:309)
at androidx.lifecycle.MutableLiveData.setValue(MutableLiveData.java:50)
OveralLeaderBoard screen has nothing to do with ProfileFragmentKt.
I have never seen this InternalSyntheticLambda, .onChanged$bridge before. You won't even find it in the class kotlin bytecode.
Can anybody tell me what this is? And how to solve it?
I had the exact same problem in the Crashlytics console of an app in production.
I managed to reproduce the crash on my phone: there were no mention of the totally unrelated fragment in my crash logs.
If fixed the crash, and there were really no reason why this unrelated fragment should be mentionned here.
So I can't explain why, but my advice would be to ignore the unrelated fragment to anyone facing this issue.
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)
I have looked through many different solutions for this problem but I cannot find one that is working for me.
My logcat has randomly stopped working properly. It seems like it has some filters set on it, but I have made sure that no filters is on and that it is looking for errors in my project. My app will crash but nothing relevant will appear in the Logcat.
I have not messed with the Gradle at all so I really don't know why it isn't working.
Here is a screenshot of my Logcat Error's after my app crashes:
I have also checked the Verbose section to see if it just wasn't being recorded in Error's, but there is nothing related to a crash anywhere.
Check your search, I think you didn't clear it.
I have an Android app out there in the market. It uses Flurry, and it reports these crashes relatively often. I could never reproduce it, and since there's no stack trace, I don't even have any idea what code triggers it. Is anyone familiar with this issue?
Update: 2 years later, I'm still getting this crash pretty often.
My app had been chugging along fine on the Android market until last night when it was reported a customer found an error. The customer must have downloaded the latest version of the app because he tried to use it again with the latest version and the error came back.
I looked at the stack trace of the error and found it was caused by a NullPointerException when passing information between two activities, namely with the onActivityResult() method.
I checked the code and can't find what could have caused the error. I tried to figure out what steps the user took to get the error, but found nothing wrong, on the emulator Android 1.6 /Android 2.2 and my own phone (Android 2.2). I couldn't find any problems no matte rhow much I tried to crash the system.
Another thing that is strange is that the particular onActivityResult method is called a lot in my app. So it is odd that only one user has reported problems.
Also, it says the user's platform is "OTHER". I don't know what device that could be.
So my questions are:
1) Could this problem be an issue with the user's device and not my application?
2)What to do when you cannot find the cause of a crash?
1) Yes, they may have a custom ROM; they're known for doing things like this.
2) Unless you can reproduce it, you [probably] can't fix it.
Can you contact this customer? If not, there may be nothing you can do.