Leaked activity not detected as a leak by LeakCanary

[ajarl]

LeakCanary Version: 1.4-beta2

So I have an activity being leaked on configuration change. I think it's a MapView-related issue, but haven't been able to fix it yet. In any case, LeakCanary takes a heap dump and says it's analyzing it, and then comes back and says that no leak was found. However, the activity is clearly leaked as the memory usage keeps increasing until the app crashes with OOM if you keep rotating the screen.

I couldn't attach the heap dump file here as it is too large, but I uploaded it here

Notice there are 6 instances of the main activity (TaxiStockholmActivity) present in the heap.

This is what LeakCanary says in the LogCat:

03-31 09:44:48.469 12169-12215/se.taxistockholm.debug I/art: hprof: heap dump "/storage/emulated/0/Download/leakcanary-se.taxistockholm.debug/suspected_leak_heapdump.hprof" starting...
...
03-31 09:45:18.355 12169-14813/se.taxistockholm.debug D/LeakCanary: In se.taxistockholm.debug:4.1:112.
                                                                    * NO LEAK FOUND.

Tested on 5.1 (emulator) and 6.0 (device), same result. This is just a wild guess, but could it be that LeakCanary is unable to find a path to a GC root, maybe because it's somehow outside of the process (e.g. in Google Play services)?

[ajarl]

I managed to fix the memory leak anyway. We weren't properly calling LocationServices.FusedLocationApi.removeLocationUpdates. Hopefully that helps to reproduce the issue so that LeakCanary can properly detect this leak as well.

[pyricau]

Thanks!

[jrodbx]

@ajarl: Thanks for providing the heap dump. Examining in MAT confirms what you found: multiple instances of TaxiStockholmActivity.

Tracing one shows that a GC root of type com.google.android.gms.location.internal.zzk$zzc (LocationClientHelper) is causing the leak and Leakcanary isn't detecting it.

Using git bisect, it looks like 3d1f524 is the reason. That commit excludes Binder GC roots from leak detection. zzk$zzc inherits from android.os.Binder.

[ash995]

app_dump_file.zip
I have attached the heap dump of my basic application in which you will be able to see that there are 34 instances of MainActivity, and leakcanary was not able to detect a leak. What could be the issue?
I am running leak canary version 1.5.4.

[JakeWharton]

Have you configured it correctly?

…

On Mon, Mar 5, 2018 at 11:54 PM Ashwin Kumar ***@***.***> wrote: app_dump_file.zip <https://github.com/square/leakcanary/files/1783558/app_dump_file.zip> I have attached the heap dump of my basic application in which you will be able to see that there are 34 instances of MainActivity, and leakcanary was not able to detect a leak. What could be the issue. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#482 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEe54p7rm0OwkzVcB0OHGVChP7MgAks5tbhaHgaJpZM4H8hb4> .

[ash995]

@JakeWharton Yeah I followed the guide to the dot. It detected a leak once, and then was not able to detect altogether.

[JakeWharton]

Can you reproduce the setup with the sample app then? This will allow us to debug why the leak isn't being found.

[jrodbx]

please file a separate issue. this issue has been closed since 2016.