Memory leak in Stetho 1.2.0

[realdadfish]

We've experienced a severe memory leak after we integrated Stetho into our app. Through bisection we could pin down the exact revision when we did this and could verify that - once Stetho was removed - the memory leak was gone.

The leak showed up in Android's Memory Monitor, where constantly around 20KB/s have been added on top until the limit was reached and GC kicked in. Then, from the lower level onwards, memory consumption raised again.

The way we integrated Stetho was fairly basic, we only enabled it in our custom Application instance via Stetho.initializeWithDefaults(this) for DEBUG builds.

[jasta]

What version of Android / device? What version of Android Studio? We've had these reports trickle in here and there for almost all of Stetho's releases but I have never been able to reproduce locally. If you could, please test the Stetho sample app for the leak as well as that is what I have used to reproduce and could not.

I understand why you would not want to send it to us, but if you could take a look at a heap dump locally to see where the possible leak suspects are that would be very helpful as well. The basic process is available in Android Studio / Android Monitor where you can collect a heap dump and open it in a tool called Eclipse Memory Analyzer. There is a pretty slick wizard to let you view the potential leak suspects and it should show up pretty easily.

P.S. If you send me your heap file I can do this analysis but it could potentially leak very sensitive information such as auth tokens and what-not. I do not recommend that you send it unless you are absolutely certain there's nothing sensitive in the file...

[MohMah]

I approve of the memory leak, my app usually takes up around 40MB of memory but after I included stetho it gradually increased up to 200MB and then multiple GCs tried to keep it under 200MB. I tried to do a memory dump but due to the low transfer rate and huge memory usage it couldn't download the memory dump from app to my pc.

[jasta]

@MohMah, can you help us track this down? I've tested this extensively on my devices and have not been able to repro. At least letting me know what Android version and device you have would be really helpful. If you could try other devices as well (in particular any Nexus series device) that would be helpful too. If you can confirm it doesn't repro on Nexus devices then we're on to something...

[ldavin]

I reproduce the issue mentioned by @tommyd3mdi on my emulator (Google Apis - Android 23 - x86_64 - rev 11) when the following conditions are met:

• App is launched on emulator
• Chrome is launched on my mac, and displays the chrome://inspect/ page

I've added an allocation tracking file (app is idle so it should only display Stetho allocations/leaks), and a heap dump.
Allocations-and-snapshot.zip

I also reproduce on my Moto X (2nd gen) running on Android 6.0

Thanks for all the work, and happy debugging :)

[jasta]

@ldavin thanks so much, I'll take a look shortly and hopefully can figure out what's going on here.

[KChernenko]

I'm using 1.3.1 version and also have a memory leak.

[Heycz]

@KChernenko I have the same problem

[jasta]

Is the only issue that leak canary believes there is a leak here? I finally analyzed @ldavin 's trace (embarrassed by how look it took) and it reveals that the only activity retained by Stetho's mActivities list is indeed also retained by the system itself (ActivityThread$ActivityClientRecord, PhoneWindow$DecorView, etc) which means that there is actually no leak here. Stetho could, of course, convert this array to a WeakReference which would likely silence LeakCanary's complaint but it seems more so that LeakCanary is actually flagging this as a false positive since Stetho will indeed remove the reference once the system removes its reference.

I am open to the idea of modifying Stetho to use a WeakReference here as it's not a functional change at all and not technically wrong either, but it is worth noting that this seems to be a LeakCanary issue.

[brianchu]

I have a similar problem. With the library, my media heavy app runs about few round of video and die. Removing the library solve the problem. The stack when it dies:

06-02 06:23:29.812 W/System.err(11169): java.io.IOException: Too many open files
06-02 06:23:29.812 W/System.err(11169): at android.net.LocalSocketImpl.accept(Native Method)
06-02 06:23:29.812 W/System.err(11169): at android.net.LocalSocketImpl.accept(LocalSocketImpl.java:328)
06-02 06:23:29.812 W/System.err(11169): at android.net.LocalServerSocket.accept(LocalServerSocket.java:94)
06-02 06:23:29.812 W/System.err(11169): at com.facebook.stetho.server.LocalSocketServer.listenOnAddress(LocalSocketServer.java:85)
06-02 06:23:29.812 W/System.err(11169): at com.facebook.stetho.server.LocalSocketServer.run(LocalSocketServer.java:74)
06-02 06:23:29.812 W/System.err(11169): at com.facebook.stetho.server.ServerManager$1.run(ServerManager.java:40)

[jasta]

@brianchu that problem is unrelated I believe. See #308, though the issue is closed because we assumed we had a fix. If you're still seeing this in the latest release, re-open the issue and we can discuss further.

[ninovanhooff]

Still seeing this in 1.4.2. com.facebook.stetho.server.onAccepted() shows a lot of allocations when profiling

[ZakTaccardi]

@jasta please convert stetho's reference to a weak one to silence leak canary, would really help out