search

firebase / firebase-android-sdk

Firebase Android SDK
https://firebase.google.com
Apache License 2.0
2.26k stars 573 forks source link

FirebaseAuthFallbackService memory leak #2387

Closed dimiitpk closed 2 years ago

dimiitpk commented 3 years ago

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

yes

[REQUIRED] Step 2: Describe your environment

[REQUIRED] Step 3: Describe the problem

LeakCanary is telling me that "FirebaseAuthFallbackService " is leaking. I just "AuthStateListener" in my ActivityClass which lives through the entire app lifecycle, to check if the user signed out. And "Firebase.auth" for taking currentUser instance. That's all

Steps to reproduce:

Happening every time I open the app, sometimes when I close the app, sometimes when It goes to the background, LeakCanary starts dumping the heap and throwing this memory leak.

Relevant Code:

┬───
│ GC Root: Global variable in native code
│
├─ com.google.firebase.auth.api.fallback.service.zza instance
│    Leaking: UNKNOWN
│    Retaining 1.7 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)
​     Retaining 1.2 kB in 9 objects
​     key = d411935b-9bcd-4a8d-8362-a6c8687aec0e
​     watchDurationMillis = 5285
​     retainedDurationMillis = 281
​     mApplication instance of com.upgrades.venue.pro.MainApplication
​     mBase instance of android.app.ContextImpl
google-oss-bot commented 3 years ago

I found a few problems with this issue:

sam-gc commented 3 years ago

Hi, thanks for reaching out. I've filed a bug internally for tracking. (b/179034484)

mikezliu commented 3 years ago

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

csechuan commented 3 years ago

[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
====================================
mj8894 commented 3 years ago

Hi,

I am getting the same issue in my application too. Is there any fix to prevent this from leaking?

nikhiljainlive commented 3 years ago

I am also facing this issue. Any fixes?

KORuL commented 3 years ago

I am also facing this issue.

nikhiljainlive commented 3 years ago

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?

mikezliu commented 3 years ago

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

pyricau commented 3 years ago

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
    )
  }
}
namgk commented 3 years ago

@pyricau silencing it is easy, but more important is, does it lead to app crash?

We run 24/7 kiosk application and ours crash once in a while. We're trying to figure it out :(

mwshubham commented 3 years ago

+1

remvst commented 3 years ago

Also seeing this issue, which causes our team to check leaks less often, since they all assume it's this specific leak we can't do anything about.

Would love to see it fixed on the firebase side

Brian605 commented 3 years ago

This issue is Causing ANR in my app

lincolnthree commented 3 years ago

Also getting ANRs from this.

ChrisKruegerDev commented 3 years ago

+1

Chani91 commented 3 years ago

@Brian605 Have you come up with a fair solution?

rafiqlightwala commented 3 years ago

Someone from the firebase team should look into this urgently!

Jack29913 commented 3 years ago

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

nahuelb commented 3 years ago

+1

alex-kurd commented 3 years ago

+1, Please fix that issue. We have a lot of ANRs in the app because of that.

Toubap commented 3 years ago

Still not fixed.. 😢

vkryachko commented 3 years ago

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.

johndoe457 commented 3 years ago

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

wangyongchao commented 3 years ago

Cause a lot of anr, the version can’t be sent out

Ahmadpashaquarterpi commented 3 years ago

+1 I am also getting anr reports because of this.

nahuelb commented 3 years ago

Anyone who fixed it by reverting to an older version?

zeusalmighty717 commented 3 years ago

+1

Leo7654 commented 3 years ago

+1

Re4GD commented 3 years ago

+1

azartx commented 3 years ago

+1

bosankus commented 3 years ago

+1 Facing exact similar issue.

nenriquez commented 3 years ago

+1 Me too using:

 // firebase
implementation platform('com.google.firebase:firebase-bom:28.4.1')
implementation 'com.google.firebase:firebase-analytics'
implementation 'com.google.firebase:firebase-auth'
implementation 'com.google.firebase:firebase-database'
implementation 'com.google.firebase:firebase-dynamic-links'
implementation 'com.google.firebase:firebase-crashlytics'
implementation 'com.google.firebase:firebase-storage'
aguatno commented 3 years ago

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.

Jack29913 commented 3 years ago

Guys it has been weeks. Can you at least give us some updates about the issue please? @vkryachko @schmidt-sebastian

vkryachko commented 3 years ago

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.

mnayef95impressions commented 2 years ago

@vkryachko @schmidt-sebastian any update on this?

miyuki-onuma commented 2 years ago

+1

anjalsaneen commented 2 years ago

+1

Chani91 commented 2 years ago

any progress? Any update?

bilicio commented 2 years ago

+1

dimiitpk commented 2 years ago

Issue is created almost 10 months ago. My app started crashing on production. Is there any progress with this?

romannotroman commented 2 years ago

Is there any update on this?

atulgpt commented 2 years ago

Yep agree there should be such memory issues in such a basic sdk. Since Android is such a fragmented ecosystem, we don't know how much severe this be in certain devices. On saying that, I want to know when can we expect thus issue to be resolved?

ghost commented 2 years ago

+1

bacarPereira commented 2 years ago

I am also facing this issue. Any fixes? 😬

malcolmdeck commented 2 years ago

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.

seanyc4 commented 2 years ago

Also experiencing this bug in a production app

bogmix commented 2 years ago

@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.

alex-kurd commented 2 years ago

@malcolmdeck

Yes, please fix that issue. Google really punishes the apps for the ANRs "bad behavior". We tried to improve all places with ANRs, but ANRs from "FirebaseAuthFallbackService" we cannot fix and that spoils everything and we still above the "ANR bad behavior threshold". Our app position last time in Google Play significantly went down because of that issue.