OkHttp resource leak with 4.0 #1996
Comments
|
I am experiencing same problem with glide 4.0.0 release, both on emulator and real devices. This happens a lot when fast-scrolling recycler view. |
|
Yeah sorry I can still reproduce this in the flickr sample :/. I'll try and get this fixed for real for the next release. |
|
Interesting I actually was reproducing this with the Glide's default HttpUrlFetcher, not the okhttp3 integration. That turns out to be an issue with redirects, I doubt the same thing applies to okhttp3. I'll investigate this next. |
sjudd
added a commit
to sjudd/glide
that referenced
this issue
Sep 8, 2017
Previously some of the logic in run() might null out the data fetcher instance variable, even if it had been set when run() was first called. As a result, the data fetcher would not be cleared. Now the initial data fetcher is held on to as a local variable so the instance variable can be freed without affecting the behavior of cleanup(). Progress towards bumptech#1996, bumptech#2352
sjudd
added a commit
to sjudd/glide
that referenced
this issue
Sep 10, 2017
In addition to v3.0.1 being super old, it looks like earlier version(s) of OkHttp have a race that will leak resources when requests are enqueued instead of executed and cancel is called. Progress towards bumptech#1996.
|
I think this is fixed, or at least I'm no longer able to trivially reproduce it. |
|
I just got another one of these, with version E/StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
java.lang.Throwable: Explicit termination method 'response.body().close()' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:223)
at java.lang.reflect.Method.invoke(Native Method)
at okhttp3.internal.platform.AndroidPlatform$CloseGuard.createAndOpen(AndroidPlatform.java:341)
at okhttp3.internal.platform.AndroidPlatform.getStackTraceForCloseable(AndroidPlatform.java:156)
at okhttp3.RealCall.captureCallStackTrace(RealCall.java:89)
at okhttp3.RealCall.enqueue(RealCall.java:98)
at com.bumptech.glide.integration.okhttp3.OkHttpStreamFetcher.loadData(OkHttpStreamFetcher.java:53)
at com.bumptech.glide.load.model.MultiModelLoader$MultiFetcher.loadData(MultiModelLoader.java:97)
at com.bumptech.glide.load.model.MultiModelLoader$MultiFetcher.startNextOrFail(MultiModelLoader.java:148)
at com.bumptech.glide.load.model.MultiModelLoader$MultiFetcher.onLoadFailed(MultiModelLoader.java:142)
at com.bumptech.glide.integration.okhttp3.OkHttpStreamFetcher.onFailure(OkHttpStreamFetcher.java:62)
at okhttp3.RealCall$AsyncCall.execute(RealCall.java:161)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)I use similar code as in the first post. |
|
Same here. After further scrolling, I get this message until the application stops responding:
I tried all the versions from 3.8.0 to 4.7.1 and this happens on all of them but only for android devices with version 8 and above. |
|
Thanks @kirilamenski, that's helpful context. It's possible the leak is fixed in Glide's usage of OkHttp, but there may be other resource leaks in OkHttp (or the Android framework) itself. |
|
@sjudd I don't know if this will be helpful too, but I found the same problem in Picasso (v. 2.71828). Sometimes it just freeze the application sometimes just throws an error: As hotfix for users I used Ion. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Glide Version:
4.0.0-SNAPSHOT, also happens with4.0.0-RCIntegration libraries:
OkHttp, same versionDevice/Android Version:
OnePlus 3, 7.1.2. Haven't tested with others yetIssue details / Repro steps / Use case background:
I recently migrated to Glide 4.0 and am now seeing these reource leak warnings from time to time. I have
StrictModewith all settings enabled. I use Glide very heaviliy inRecyclerViewswith multiple images per line (about 6 on screen mostly). I don't know too much about the internals of Glide, so I may be doing something wrong. Apart from this everything seems to work properly.Glide load line /
GlideModule(if any) / list Adapter code (if any):My
GlideModule:A typical load line:
Also note, that I use this in my
RecyclerView.Adapters:I thought that would help freeing memory and clearing any ongoing requests. Am I supposed to do this?
Stack trace / LogCat (Formatted for readability):
If you need any more information or prefer
Javacode instead ofKotlin(I was to lazy to rewrite it), please let me know!The text was updated successfully, but these errors were encountered: