Okhttp: Strict Mode Error: Explicit termination method 'close' not called
Wounder if anyone else has seen this strict mode violation, it could be my own code but if it is I can't see how.
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 'close' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:180)
at java.io.FileInputStream.<init>(FileInputStream.java:78)
at okio.Okio.source(Okio.java:163)
at okhttp3.internal.io.FileSystem$1.source(FileSystem.java:44)
at okhttp3.internal.DiskLruCache$Entry.snapshot(DiskLruCache.java:1004)
at okhttp3.internal.DiskLruCache.get(DiskLruCache.java:431)
at okhttp3.Cache.get(Cache.java:193)
at okhttp3.Cache$1.get(Cache.java:143)
at okhttp3.internal.http.HttpEngine.sendRequest(HttpEngine.java:198)
at okhttp3.RealCall.getResponse(RealCall.java:240)
at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:198)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:160)
at okhttp3.RealCall.access$100(RealCall.java:30)
at okhttp3.RealCall$AsyncCall.execute(RealCall.java:127)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)
Wavesonics
All 20 comments
What version? What's your calling code? The trace isn't that useful by
itself.
On Fri, Apr 15, 2016, 7:41 PM Adam Brown [email protected] wrote:
Wounder if anyone else has seen this strict mode violation, it could be my
own code but if it is I can't see how.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 'close' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:180)
at java.io.FileInputStream.(FileInputStream.java:78)
at okio.Okio.source(Okio.java:163)
at okhttp3.internal.io.FileSystem$1.source(FileSystem.java:44)
at okhttp3.internal.DiskLruCache$Entry.snapshot(DiskLruCache.java:1004)
at okhttp3.internal.DiskLruCache.get(DiskLruCache.java:431)
at okhttp3.Cache.get(Cache.java:193)
at okhttp3.Cache$1.get(Cache.java:143)
at okhttp3.internal.http.HttpEngine.sendRequest(HttpEngine.java:198)
at okhttp3.RealCall.getResponse(RealCall.java:240)
at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:198)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:160)
at okhttp3.RealCall.access$100(RealCall.java:30)
at okhttp3.RealCall$AsyncCall.execute(RealCall.java:127)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2487
JakeWharton
on 16 Apr 2016
Ya I noticed!
library version: 3.2.0
I've Been looking through all my networking code, going on the assumption that this is referring to the response body, but everywhere I deal with the response body it's closed in a finally:
@Override
public void onResponse( final Call call, final Response response ) throws IOException
{
try
{
// Response handling
}
finally
{
response.body().close();
}
}
Getting a similar error when calling chain.proceed(chain.request()) in the intercept(Chain chain) method in an Interceptor. We're using version 3.2.0.
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 'close' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:180)
at java.io.FileOutputStream.<init>(FileOutputStream.java:89)
at okio.Okio.appendingSink(Okio.java:182)
at okhttp3.internal.io.FileSystem$1.appendingSink(FileSystem.java:59)
at okhttp3.internal.DiskLruCache.newJournalWriter(DiskLruCache.java:304)
at okhttp3.internal.DiskLruCache.rebuildJournal(DiskLruCache.java:415)
at okhttp3.internal.DiskLruCache.initialize(DiskLruCache.java:235)
at okhttp3.internal.DiskLruCache.get(DiskLruCache.java:424)
at okhttp3.Cache.get(Cache.java:193)
at okhttp3.Cache$1.get(Cache.java:143)
at okhttp3.internal.http.HttpEngine.sendRequest(HttpEngine.java:198)
at okhttp3.RealCall.getResponse(RealCall.java:240)
at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:198)
ronocod
on 21 Apr 2016
@ronocod that actually looks like a slightly different stack trace. Are you releasing your reference to OkHttpClient?
dave-r12
on 21 Apr 2016
Please paste your interceptor code.
On Thu, Apr 21, 2016, 8:01 AM Dave Roberge [email protected] wrote:
@ronocod https://github.com/ronocod that actually looks like a slightly
different stack trace. Are you releasing your reference to OkHttpClient?—
You are receiving this because you commented.Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2487#issuecomment-212884119
JakeWharton
on 21 Apr 2016
@dave-r12 I don't think we're holding any unusual references to OkHttpClient that need to be released.
A -
@Override public Response intercept(Chain chain) throws IOException {
if (checkA()) {
Response response = chain.proceed(chain.request());
if (checkB()) {
return response;
} else {
if (response != null) {
response.body().close();
}
throw new IOException(CAUSE_A);
}
} else {
throw new IOException(CAUSE_B);
}
}
​
B -
@Override public Response intercept(Chain chain) throws IOException {
for (int i = 0; i <= MAX_RETRIES; i++) {
try {
return chain.proceed(chain.request());
} catch (IOException e) {
if (i == MAX_RETRIES) {
throw e;
} else {
backoff();
}
}
}
throw new IOException(CAUSE);
}
@ronocod Response Body have to be CLEAR in all cases including errors.
iNoles
on 22 Apr 2016
Sorry, that probably wasn't clear. To me, the stack trace from @ronocod suggests either the application is leaking a Cache instance without closing it, or there is a file leak in the DiskLruCache, specifically the journal writer.
@ronocod can you confirm you're not leaking an OkHttpClient/Cache instance in your app? Are you holding onto a strong reference to OkHttpClient for the entire lifetime of your app?
dave-r12
on 22 Apr 2016
@dave-r12 I am holding onto a static instance of OkHttpClient, which it's self is holding onto the cache (_I'm just newing it up and passing it to the builder, none of my code directly references the cache_).
Are you thinking that could somehow be leaking these cache responses?
My somewhat uninformed guess is this could be in Cache.get()
Wavesonics
on 26 Apr 2016
@Wavesonics no, I was referring to the stack trace that @ronocod pasted. Your stack trace is different. If you believe you are closing the response body in all code paths, can you try to reproduce the issue you are seeing with a failing test case, or pared down example?
dave-r12
on 26 Apr 2016
I met the stack trace in Strict Mode too，please help to see the code, Should I need to move "response.body().close(); " in finally{ }? I test this way may be effective。
public void onResponse(@NonNull Call call, @NonNull Response response) throws IOException {
try {
SystemUtils.checkContextValid(mCtx);
if (response.isSuccessful()) {
onResponseSuccessful(mCtx, call, response);
} else if (response.isRedirect()) {
onResponseRedirect(mCtx, call, response);
} else {
onResponseError(mCtx, call, response);
}
} catch (Exception e) {
e.printStackTrace();
}
response.body().close();
}
bingxuebage
on 10 May 2016
That works. A finally clause is even better.
swankjesse
on 10 May 2016
@swankjesse sorry, still exist though move "response.body().close(); " in finally{ }，seem stack trace to @Wavesonics
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 'close' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:184)
at java.io.FileInputStream.<init>(FileInputStream.java:78)
at okio.Okio.source(Okio.java:163)
at okhttp3.internal.io.FileSystem$1.source(FileSystem.java:44)
at okhttp3.internal.DiskLruCache$Entry.snapshot(DiskLruCache.java:1004)
at okhttp3.internal.DiskLruCache.get(DiskLruCache.java:431)
at okhttp3.Cache.get(Cache.java:193)
at okhttp3.Cache$1.get(Cache.java:143)
at okhttp3.internal.http.HttpEngine.sendRequest(HttpEngine.java:198)
at okhttp3.RealCall.getResponse(RealCall.java:240)
at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:198)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:160)
at okhttp3.RealCall.access$100(RealCall.java:30)
at okhttp3.RealCall$AsyncCall.execute(RealCall.java:127)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)
Yeah I've checked and checked and all of my response body's are closed on a finally.
Also interesting is it's only cached responses.
Wavesonics
on 11 May 2016
I got the same exception with OkHttp 3.3.0. So far, I couldn't reproduce the problem with OkHttp 3.4.1, but that could be because this issue is extremely hard to get (probably a race condition).
We got this exception when running okHttpClient.newCall(request).execute() and canceling the task because the activity gets destroyed. It seems that the DiskLruCache.Snapshot snapshot from Cache.get(Request) is finalized, but the underlying FileInputStream isn't closed.
I'll update my comment as soon as I have any news.
mreichelt
on 11 Jul 2016
I got the same StrictMode error. It was fixed by adding cache.close() at the end of onResponse and onFailure .
Hope it helps.
2kking
on 31 Aug 2016
Please don’t call cache.close() until you’re completely done with your response cache.
swankjesse
on 31 Aug 2016
@swankjesse I think cache has been finished before onResponse.
2kking
on 1 Sep 2016
I'm with error too, but I'm not getting resolve it
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 'close' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:184)
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:287)
at com.android.okhttp.Connection.upgradeToTls(Connection.java:201)
at com.android.okhttp.Connection.connect(Connection.java:155)
at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:276)
at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:211)
at com.android.okhttp.internal.http.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:382)
at com.android.okhttp.internal.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:332)
at com.android.okhttp.internal.http.HttpURLConnectionImpl.getHeaderField(HttpURLConnectionImpl.java:161)
at com.android.okhttp.internal.http.DelegatingHttpsURLConnection.getHeaderField(DelegatingHttpsURLConnection.java:190)
at com.android.okhttp.internal.http.HttpsURLConnectionImpl.getHeaderField(HttpsURLConnectionImpl.java:25)
at org.fdroid.fdroid.net.HttpDownloader.download(HttpDownloader.java:89)
at org.fdroid.fdroid.IndexV1Updater.update(IndexV1Updater.java:102)
at org.fdroid.fdroid.UpdateService.onHandleIntent(UpdateService.java:468)
at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.os.HandlerThread.run(HandlerThread.java:61)
soaresdiogo
on 14 Nov 2018
I have similar issue with v 3.11.0, see in logs this error:
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 'close' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:180)
at com.android.org.conscrypt.Platform.closeGuardOpen(Platform.java:282)
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:316)
at com.android.okhttp.Connection.connectTls(Connection.java:235)
at com.android.okhttp.Connection.connectSocket(Connection.java:199)
at com.android.okhttp.Connection.connect(Connection.java:172)
at com.android.okhttp.Connection.connectAndSetOwner(Connection.java:367)
at com.android.okhttp.OkHttpClient$1.connectAndSetOwner(OkHttpClient.java:130)
at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:329)
at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:246)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:457)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:405)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:521)
at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java)
at android.media.MediaHTTPConnection.seekTo(MediaHTTPConnection.java:211)
at android.media.MediaHTTPConnection.readAt(MediaHTTPConnection.java:326)
at android.media.MediaHTTPConnection.native_readAt(Native Method)
at android.media.MediaHTTPConnection.readAt(MediaHTTPConnection.java:315)
at android.media.IMediaHTTPConnection$Stub.onTransact(IMediaHTTPConnection.java:72)
at android.os.Binder.execTransact(Binder.java:565)
I'm not sure, but everything seems to be working.
evgentset
on 22 Nov 2018
Related issues
arturdryomov
·
50Comments
swankjesse
·
100Comments
bxqgit
·
61Comments
Vampire
·
48Comments
chrisbanes
·
48Comments