Memory leak detected by LeakCanary

[rockerhieu]

Since stetho isn't available for release version, I think we're fine. But memory leak is memory leak and I think we should eliminate it:

05-19 01:50:00.596  30932-31353/com.company.app D/LeakCanary﹕ * android.content.ContentResolver$CursorWrapperInner (ChatRoomsFragment's cursor) has leaked:
05-19 01:50:00.596  30932-31353/com.company.app D/LeakCanary﹕ * GC ROOT static com.facebook.stetho.inspector.elements.android.ActivityTracker.sInstance
05-19 01:50:00.596  30932-31353/com.company.app D/LeakCanary﹕ * references com.facebook.stetho.inspector.elements.android.ActivityTracker.mActivities
05-19 01:50:00.596  30932-31353/com.company.app D/LeakCanary﹕ * references java.util.ArrayList.array
05-19 01:50:00.596  30932-31353/com.company.app D/LeakCanary﹕ * references array java.lang.Object[].[0]
...

[jasta]

Err, I haven't personally checked out LeakCanary but I'm willing to bet this is either a false positive or representative of a different kind of bug. ActivityTracker is designed to keep a strong reference to all activities that were not destroyed so that they can be "seen" by Stetho. When you destroy the activity, however, it should definitely be removed. If that's not the case then the leak is legitimate, but I doubt that's true nominally given that we trust the Android framework itself to tell us when the removal occurs.

[edward-s]

im getting the same leak in leakcanary also
GC ROOT static com.facebook.stetho.inspector.elements.android.ActivityTracker.sInstance

any way to fix this?

[155martinmoreno]

me too... is eating 50k per second of memory

[jasta]

Can one of you folks seeing this actually look into the ActivityTracker to see why it isn't releasing activity references for you? I did some spelunking and could not find any leak on my N5/Lollipop device.

[laoda512]

I found the same question too. Although GC will release such memory, it's strange to see allocated memory increase every second...

[jasta]

FWIW, I still can't repro this and have no concrete information on which to operate. Can anyone provide some details here? What is leaking? What is it's path to the GC root? Why do you believe it should have been released?

[rickbrew]

And which version of Android is it happening on?

[Actine]

+1. Noticed my memory was being eaten up, quick allocation dump identified Stetho was a culprit

Take a look at your networking logic. Looks like it keeps allocating new stream buffers around com.facebook.stetho.server.LocalSocketHttpServerConnection.LocalSocketSessionInputBuffer / ...OutputBuffer. It's not a memory leak (it indeed gets GC'd), but slow memory churn.

[jasta]

What about this screenshot is telling you that stetho is leaking memory in the networking layer? This is a list of allocations which proves it is simply using memory. And the amounts shown look quite reasonable given that it is indeed using an Apache HttpClient HTTP server. I don't see any actual evidence from my own profiles of stetho-sample that stetho leaks. A heap dump and a watch on dumpsys meminfo com.facebook.stetho.sample all look perfectly normal.

[Actine]

@jasta well, the alllocation dump was taken over the course of roughly 1 second of the app being idle, and there were 6 allocations of 12KiB buffers, all coming from LocalSocketHttpServerConnection.bind(). This is regardless whether I am currently connected via chrome tools or not. It feels like three 12KiB buffers get allocated each second and then thrown away to be GC'ed. Again, this is not memory leak, but nonetheless IMHO this should not be happening, as buffers by definition should be flushed and reused rather than thrown away. Not mentioning that this is messing with profiling the rest of the app.

P.S. In fact I am not sure if this is related to the reported "memory leak" issue and whatever LeakCanary reports, but judging from the comments my symptoms were similar so I didn't open a new issue. Maybe this is a different issue.

[jasta]

It should be noted that merely with chrome://inspect open Chrome will poll stetho every second making 3 network requests. These requests allocate new buffers in Apache http client. This is unavoidable and we do our best to buffer the response inside Stetho itself. See ChromeDiscoveryHandler. I don't believe this is a memory leak or even a significant amount of memory churn all things considered and it can be stopped by closing the inspect chrome windows.

[Actine]

@jasta Oh, you're right. Sorry then :)

[jasta]

Unable to repro, closing...