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

image

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)

Most upvoted comments

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:

public class CrashlyticsUncaughtExceptionHandler {
   /** Must be run after Crashlytics has initialized. */
   static void addTimeoutToCrashlyticsUncaughtExceptionHandler() {
       Thread.UncaughtExceptionHandler crashlyticsHandler = Thread.getDefaultUncaughtExceptionHandler();
       // If the Crashlytics uncaught exception handler timeout, the report
       // will be uploaded on the next app launch in a background thread.
       Thread.setDefaultUncaughtExceptionHandler(
               (thread, ex) -> {
                   if (crashlyticsHandler != null) {
                       CountDownLatch latch = new CountDownLatch(1);
                       new Thread(
                               () -> {
                                   crashlyticsHandler.uncaughtException(thread, ex);
                                   latch.countDown();
                               })
                               .start();
                       com.google.firebase.crashlytics.internal.common.Utils.awaitUninterruptibly(latch, 2, TimeUnit.SECONDS);
                   }
               });
   }
}

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.