firebase-android-sdk: FirebaseAuthFallbackService memory leak

I heard that they will assign this to a software engineer intern in summer of 2035

Today is Jan 1, 2022, the issue was reported on Jan 31, 2021…

After @malcolmdeck finished the refactoring, I am able to verify that the memory leak is no longer reproducible in the latest firebase-auth pre-release library. Will follow up here when the release goes out.

@malcolmdeck

Hey Malcolm, thank you for communicating the state of affairs. Much appreciated. I’m not sure if you know this, but Google Play punishes severely apps for exhibiting ANR behaviour. This bug persist for more than 9!!! months, in many cases it sends apps above “Bad behaviour threshold” and simply kills them - it infuences not just organic growth, it also kills paid Admob’s ads performance (since it’s also takes into account “app’s quality”). It’s need to be fixed or hotfixed now, we don’t care wether you’ll rewrite your “internal library” or implement some workaround, it should be resolved. This bug and how it’s handled so far, it’s simply unacceptable.

Hi all, thank you for your patience! The fix is finally out in Firebase Authentication version 21.0.2. You may check out the release notes here. With that said, I’ll be closing this issue now. Feel free to open a new issue if there are any other concerns or questions. Thanks!

Hey folks, Malcolm from the Firebase team here.

We are aware of this issue, and 3 different people have looked at it. A combination of the fact that this appears to be connected to an internal library that we depend on and the reproduction of the bug has weird interplay with our obfuscation pipeline is making this difficult for us to track down and fix. The only way we know for sure to fix this right now would be to rewrite a very large section of our library to not use that internal library (which may not fix the issue, but at least would make it easier to debug). We don’t really have the resources right now to do that, so we’re trying to see if we can figure out how to fix it without having to rewrite everything.

I know this is frustrating for you, and we’re doing the best we can. I’ll come back when I have something meaningful/new to share here. In the meantime, I appreciate your patience.

Is there any ETA for a fix or an older version we can revert to? I’m getting a lot of memory leak reports from leakcanary for this issue

As Malcolm mentioned in the comment, we have an on-going refactoring. We will update this thread once we test the refactoring and get it ready for release.

I’m just going to leave this here: https://twitter.com/Piwai/status/1473315039188762632

😉

Hi All, sorry for taking this long. This issue has been escalated with our engineering team, and we’ll provide an update as soon as possible. We thank you for your patience while we’re working on resolving this.

@yoyomyo Can you please give an estimation of the time frame that you expect to have a version with this problem fix, days, weeks or months? Because we have solutions that depended on this issue being fix, and this problem is making apps not working on some devices and get bad reviews because of it, and we need to know if we need to find a workaround or wait for a fix

The fix is not in 29.1.0 yet. Please be patient, as the BOM testing and release process can take some time. We will update this thread as soon as we have more details.

Hey firebase team will you address this issue? We are getting tons of ANR’s because of this! @vkryachko @schmidt-sebastian

The Firebase team should definitely fix this bug in FirebaseAuthFallbackService.

In the meantime, here’s how you can configure LeakCanary to stop tracking FirebaseAuthFallbackService:

First, disable the automatic install:

<?xml version="1.0" encoding="utf-8"?>
<resources>
  <bool name="leak_canary_watcher_auto_install">false</bool>
</resources>

Then install LeakCanary manually in your debug application, ignoring FirebaseAuthFallbackService:

class DebugExampleApplication : ExampleApplication() {

  override fun onCreate() {
    super.onCreate()

    val delegate = ReachabilityWatcher { watchedObject, description ->
      if (watchedObject::class.java.name != "com.google.firebase.auth.api.fallback.service.FirebaseAuthFallbackService
​  instance") {
        AppWatcher.objectWatcher.expectWeaklyReachable(watchedObject, description)
      }
    }

    val watchersToInstall = AppWatcher.appDefaultWatchers(application, delegate)

    AppWatcher.manualInstall(
      application = application,
      watchersToInstall = watchersToInstall
    )
  }
}

This issue is Causing ANR in my app

@vkryachko @schmidt-sebastian any update on this?

Why did this issue suddenly get traffic? I didn’t think it would help, but it seems like it does 😃

Hey folks, sorry that it’s taking this long. I’ve forwarded this issue to the Auth team, there is an internal bug tracking progress for this. cc @malcolmdeck

Thanks for your patience.

any progress? Any update?

+1

Hi @Jack29913 , as @aguatno mentioned, the issue is assigned and is being worked on at the moment. I know it’s been a while, so thanks for you patience.

I am getting this issue frequently whenever I am exiting the app or going into the background from my app. Refer below for heap analysis result:

====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS

References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.

1533 bytes retained by leaking objects
Signature: d7eca9435653e8afa0dd1f85b3ecd43847de7e26
┬───
│ GC Root: Global variable in native code
│
├─ com.google.firebase.auth.api.fallback.service.zza instance
│    Leaking: UNKNOWN
│    Retaining 2.1 kB in 10 objects
│    zza instance of com.google.firebase.auth.api.fallback.service.
│    FirebaseAuthFallbackService
│    ↓ zza.zza
│          ~~~
╰→ com.google.firebase.auth.api.fallback.service.FirebaseAuthFallbackService
​  instance
​     Leaking: YES (ObjectWatcher was watching this because com.google.firebase.
​     auth.api.fallback.service.FirebaseAuthFallbackService received
​     Service#onDestroy() callback and Service not held by ActivityThread)
​     Retaining 1.5 kB in 9 objects
​     key = b30e018a-f7f7-46a2-8195-64a7c1c73d6d
​     watchDurationMillis = 5251
​     retainedDurationMillis = 245
​     mApplication instance of com.nikhiljain.fundoonotes.MyApplication
​     mBase instance of android.app.ContextImpl
====================================
0 LIBRARY LEAKS

A Library Leak is a leak caused by a known bug in 3rd party code that you do
not have control over.
See https://square.github.
io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS

An unreachable object is still in memory but LeakCanary could not find a strong
reference path
from GC roots.
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: samsung
LeakCanary version: 2.7
App process name: com.nikhiljain.fundoonotes
Stats: LruCache[maxSize=3000,hits=3845,misses=86152,hitRate=4%]
RandomAccess[bytes=3983274,reads=86152,travel=69821486786,range=36820301,size=47
266607]
Heap dump reason: 1 retained objects, app is not visible
Analysis duration: 12396 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-com.nikhiljain.
fundoonotes/2021-07-04_21-31-03_017.hprof
Heap dump timestamp: 1625414484796
Heap dump duration: 9336 ms
====================================

Is there any progress on the fix of this issue?

Echoing @mohitrajput-trell - I’d love to test a patched build of this if information is forthcoming 😃

Is there any update on this issue? Which Firebase library version has fix of this issue?

Also experiencing this bug in a production app

[READ] Step 1: Are you in the right place?

yes

[REQUIRED] Step 2: Describe your environment

Android Studio version: 4.2 Beta 6 Firebase Component: Firebase Authentication Component version: 20.0.4

[REQUIRED] Step 3: Describe the problem

LeakCanary is telling me that "FirebaseAuthFallbackService " is leaking. Just add the firebase bom and firebase auth. Run the app with leak canary enabled, and bring the app to background.

Steps to reproduce:

1. Create a new project
2. Add leakcanary, firebase bom and firebase-auth lib debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.7' implementation platform('com.google.firebase:firebase-bom:27.0.0') implementation 'com.google.firebase:firebase-auth-ktx'
3. Run the app, click home button (or whatever it takes to bring the app to background).
4. For a short while, leak canary will report a leak as attached below.

Relevant Code: ==================================== HEAP ANALYSIS RESULT ==================================== 1 APPLICATION LEAKS

References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.

1325 bytes retained by leaking objects
Signature: d7eca9435653e8afa0dd1f85b3ecd43847de7e26
┬───
│ GC Root: Global variable in native code
│
├─ com.google.firebase.auth.api.fallback.service.zza instance
│    Leaking: UNKNOWN
│    Retaining 1.9 kB in 10 objects
│    zza instance of com.google.firebase.auth.api.fallback.service.FirebaseAuthFallbackService
│    ↓ zza.zza
│          ~~~
╰→ com.google.firebase.auth.api.fallback.service.FirebaseAuthFallbackService instance
​     Leaking: YES (ObjectWatcher was watching this because com.google.firebase.auth.api.fallback.service.
​     FirebaseAuthFallbackService received Service#onDestroy() callback and Service not held by ActivityThread)
​     Retaining 1.3 kB in 9 objects
​     key = 0926f4f3-852f-465d-9f35-79c785261aae
​     watchDurationMillis = 5129
​     retainedDurationMillis = 125
​     mApplication instance of com.example.MainApplication
​     mBase instance of android.app.ContextImpl
====================================
0 LIBRARY LEAKS

A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS

An unreachable object is still in memory but LeakCanary could not find a strong reference path
from GC roots.
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: Google
LeakCanary version: 2.7
App process name: com.example
Stats: LruCache[maxSize=3000,hits=2124,misses=61170,hitRate=3%]
RandomAccess[bytes=2972109,reads=61170,travel=22600881259,range=18406153,size=24436593]
Heap dump reason: 1 retained objects, app is not visible
Analysis duration: 5421 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-com.example/2021-04-15_00-36-43_029.hprof
Heap dump timestamp: 1618418210378
Heap dump duration: 1867 ms
====================================