firebase-android-sdk: ANR from crashlytics related to Firebase
[REQUIRED] Step 2: Describe your environment
Versions:
classpath 'com.google.firebase:firebase-crashlytics-gradle:2.9.2'
implementation 'com.google.firebase:firebase-crashlytics-ktx:18.3.2'
implementation 'com.google.firebase:firebase-analytics-ktx:21.2.0'
[REQUIRED] Step 3: Describe the problem
We facing this issue for almost 3 months now. But recently the ANR count is insanely high as you can see in the above From crashlytics:
main (timed waiting):tid=1 systid=19557
at jdk.internal.misc.Unsafe.park(Unsafe.java)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1079)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1369)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:278)
at com.google.firebase.crashlytics.internal.common.Utils.awaitEvenIfOnMainThread(Utils.java:22)
at com.google.firebase.crashlytics.internal.common.CrashlyticsController.handleUncaughtException(CrashlyticsController.java:94)
at com.google.firebase.crashlytics.internal.common.CrashlyticsController$1.onUncaughtException(CrashlyticsController.java:94)
at com.google.firebase.crashlytics.internal.common.CrashlyticsUncaughtExceptionHandler.uncaughtException(CrashlyticsUncaughtExceptionHandler.java:26)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1073)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)
at java.lang.Thread.dispatchUncaughtException(Thread.java:2306)
Relevant Code:
// TODO(you): code here to reproduce the problem
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 14
- Comments: 47 (15 by maintainers)
Is there any updates on this issue?
Hey @gongwen,
Sorry for the late replying, the fix is in Crashlytics
18.3.6
which announced on March 24th. With the change it will reduce the ANR and we are still working on SDK thread refactoring.We are aware of this issue. We have some work planned that will reduce the load on the main thread, which should resolve this issue as well. I will keep this thread updated.
The issue started to surface roughly one year ago - surely you have the resources to do more than just “should resolve…”.
This is a product used by millions world wide and it really should get a higher priority.
Hi @adek, that looks like an interesting finding. So in your case, the issue arises when sending push notifications. Could you share a bit more of your stacktrace? So we can check if this issue is another or related to this current one. And if it’s possible could you share a minimal repro of your issue? It’ll help us investigate this further. Thanks!
This should not have been closed. The issue is still present in the latest stable version.
Hi folks,
The Crashlytics uncaught exception handler is doing a bit too much work on the crashing thread. If that is the main thread, and has already been blocked for a few seconds, this can lead to an ANR. We are currently working on refactoring the SDK to avoid this, and the first fix will be included in the next release scheduled for March 23. In the meantime, you can manually add a timeout by doing this in your app, and below is an example:
Is it safe to just abort the Crashlytics uncaught exception handler when it’s taking too long, because Crashlytics will send any pending reports on the next app launch. Thank you again for your patience!
Is there any update on this issue, we are also facing a large volume of ANRs.