Does RotationPersist leak the Activity?

[otamate]

If I add LeakCanary by just putting

    LeakCanary.install(getApplication());

in the MainActivity's onCreate(), then

    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1' 
    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1' 

to the build.gradle dependencies, I find that hitting BACK during the counter increment reports a "suspected leak" in the log and the LeakCanary "Brr..." screen comes up. In fact, you also get it if you just rotate a few times when the counter is running but exit after it has completed normally. Is this a real leak?

01-15 16:37:53.960 4308-4324/com.morihacky.android.rxjava I/art: hprof: heap dump "/storage/sdcard/Download/leakcanary/suspected_leak_heapdump.hprof" starting...

[Kaushik Gopal]

So the screenshot of the toast message you posted is definitely not a leak. It's Leak Canary creating a heap dump. This snippet of code explains that.

I find that hitting BACK during the counter increment reports a "suspected leak"

Can you point me to the precise example that you suspect the leak and also the precise steps you're using?

Usually if you get a memory leak, leak canary will be very explicit about it. it'll pop up a notification on the top saying leak detected, so i'm inclined to say there isn't a leak (but that could be an oversight).

Preemptively closing this issue now but feel free to reopen it if you still suspect something fishy.

[otamate]

I also think there's no leak but there is scope for one, and leak canary is getting confused. The Activity creates an anonymous inner thread to do its work when it creates the Observable. This thread is doing the counting work and will survive an orientation change as it lives in the process, even though the Activity is destroyed. Taken to its extreme, if this thread took several minutes to complete the new Activities would all be up and running way before it terminated on each orientation change. Only when the initial thread stopped would that first Activity then be eligible for GC and the ref held by it would then be released. I also ran it in AS whilst monitoring mem use and rotating the device quickly, many times, and mem use always returned to the initial level eventually. Btw I have this issue in an app of my own doing the same thing and came across yours whilst researching it.

[Kaushik Gopal]

Quick follow up to your original comment: when you say your adding Leak Canary to the Main Activity? Why are you doing this again? LeakCanary is already installed for this repo using the refWatcher in the Application class which is the documented way of installing it. Are you by chance adding it twice?

[otamate]

Hi Kaushik

On 19/01/2016 16:28, Kaushik Gopal wrote:

Quick follow up to your original comment: when you say your adding
Leak Canary to the Main Activity? Why are you doing this again?
LeakCanary is already installed for this repo using the refWatcher in
the Application class which is the documented way of installing it.
Are you by chance adding it twice?

It had no effect. As it happens I think we are ok.
You might be interested in the drafts of my article, at the end of Part
2 I go into the Activity leak confusion.

https://medium.com/@carl.whalley/the-reactive-revolution-rxandroid-and-how-it-finally-clicked-for-me-a3ffc5091f5d
https://medium.com/@carl.whalley/the-reactive-revolution-rxandroid-and-how-it-finally-clicked-for-me-part-2-of-2-bafefeac9c33

Thanks for your help with this, and any comments you have on my Medium
post are very welcome!

-- Carl Whalley

—
Reply to this email directly or view it on GitHub
#40 (comment).