New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 726193 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug



Sign in to add a comment

JavaUrlRequest has race which results in leak

Project Member Reported by pauljensen@chromium.org, May 25 2017

Issue description

Chrome Version: ToT
OS: Android

What steps will reproduce the problem?
git cl patch 2903193002
./components/cronet/tools/cr_cronet.py build-test -f UploadDataProvidersTest#testGzipCancel

What is the expected result?
test passes

What happens instead?
test crashes (if fixes from patched CL aren't included)

Internal bug b/38497959

I think there may be several leaks:

Possible leak #1:

JavaUrlRequest.cancel() calls mCallbackAsync.onCanceled() which calls closeResponseChannel() which reads mResponseChannel...but does so on the callee's thread rather than the SerializingExecutor...and mResponseChannel hasn't been set yet...but will be set later during the task posted by fireGetHeaders().

Possible leak #2:

JavaUrlRequest.cancel() sets mState to CANCELLED and then sets mCurrentUrlConnection to null.  However both of these actions could happen after the mState check for CANCELLED in the Runnable posted by fireOpenConnection(), but before the Runnable posted by fireOpenConnection() has set mCurrentUrlConnection, in which case mCurrentUrlConnection will be set but fireDisconnect() will not do take any action because mCurrentUrlConnection was null.  This is similar to "Possible leak #1" in taht mCurrentUrlConnection is accessed on different threads.

If the URL being fetched is served gzip encoded this triggers a strict mode violation deep inside OkHttp where a java.util.zip.Inflater is used, which is a java.io.Closeable Object:

StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
StrictMode: java.lang.Throwable: Explicit termination method 'end' not called
StrictMode: 	at dalvik.system.CloseGuard.open(CloseGuard.java:180)
StrictMode: 	at java.util.zip.Inflater.<init>(Inflater.java:104)
StrictMode: 	at com.android.okhttp.okio.GzipSource.<init>(GzipSource.java:62)
StrictMode: 	at com.android.okhttp.internal.http.HttpEngine.unzip(HttpEngine.java:645)
StrictMode: 	at com.android.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:821)
StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:463)
StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:405)
StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getHeaders(HttpURLConnectionImpl.java:162)
StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getHeaderFieldKey(HttpURLConnectionImpl.java:214)
StrictMode: 	at org.chromium.net.impl.JavaUrlRequest$4.run(JavaUrlRequest.java:595)
StrictMode: 	at org.chromium.net.impl.JavaUrlRequest$8.run(JavaUrlRequest.java:711)
StrictMode: 	at org.chromium.net.impl.JavaUrlRequest$SeriaizingExecutor$1.run(JavaUrlRequest.java:150)
StrictMode: 	at org.chromium.net.impl.JavaUrlRequest$1$1.run(JavaUrlRequest.java:213)
StrictMode: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
StrictMode: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
StrictMode: 	at org.chromium.net.impl.JavaCronetEngine$1$1.run(JavaCronetEngine.java:58)
StrictMode: 	at java.lang.Thread.run(Thread.java:761)

After I attempted to fix "Possible leak #1" I ran into this crash which I believe is a symptom of "Possible leak #2":

StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
StrictMode: java.lang.Throwable: Explicit termination method 'close' not called
StrictMode: 	at dalvik.system.CloseGuard.open(CloseGuard.java:180)
StrictMode: 	at java.net.AbstractPlainSocketImpl.create(AbstractPlainSocketImpl.java:103)
StrictMode: 	at java.net.Socket.createImpl(Socket.java:470)
StrictMode: 	at java.net.Socket.getImpl(Socket.java:536)
StrictMode: 	at java.net.Socket.setSoTimeout(Socket.java:1127)
StrictMode: 	at com.android.okhttp.Connection.connectSocket(Connection.java:195)
StrictMode: 	at com.android.okhttp.Connection.connect(Connection.java:172)
StrictMode: 	at com.android.okhttp.Connection.connectAndSetOwner(Connection.java:367)
StrictMode: 	at com.android.okhttp.OkHttpClient$1.connectAndSetOwner(OkHttpClient.java:130)
StrictMode: 	at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:329)
StrictMode: 	at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:246)
StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:457)
StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:126)
StrictMode: 	at org.chromium.net.impl.JavaUrlRequest$7.run(JavaUrlRequest.java:696)
StrictMode: 	at org.chromium.net.impl.JavaUrlRequest$8.run(JavaUrlRequest.java:708)
StrictMode: 	at org.chromium.net.impl.JavaUrlRequest$SeriaizingExecutor$1.run(JavaUrlRequest.java:150)
StrictMode: 	at org.chromium.net.impl.JavaUrlRequest$1$1.run(JavaUrlRequest.java:213)
StrictMode: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
StrictMode: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
StrictMode: 	at org.chromium.net.impl.JavaCronetEngine$1$1.run(JavaCronetEngine.java:58)
StrictMode: 	at java.lang.Thread.run(Thread.java:761)
 
I included a couple potential fixes in https://codereview.chromium.org/2903193002
Owner: pauljensen@chromium.org
Project Member

Comment 3 by bugdroid1@chromium.org, May 31 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8f8aa43973e496a65d9eecfa3e6f8b8dd68432e7

commit 8f8aa43973e496a65d9eecfa3e6f8b8dd68432e7
Author: pauljensen <pauljensen@chromium.org>
Date: Wed May 31 16:49:38 2017

[Cronet]  Fix two races/leaks in JavaUrlRequest

The underlying InputStream and HttpURLConnection were accessed on different
threads which during cancellation could result in races resulting in leaks
that StrictMode catches. Shift all accesses to these variables to one
thread like the Chromium threading principles recommends.

BUG= 726193 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester

Review-Url: https://codereview.chromium.org/2903193002
Cr-Commit-Position: refs/heads/master@{#475945}

[modify] https://crrev.com/8f8aa43973e496a65d9eecfa3e6f8b8dd68432e7/components/cronet/android/java/src/org/chromium/net/impl/JavaUrlRequest.java
[modify] https://crrev.com/8f8aa43973e496a65d9eecfa3e6f8b8dd68432e7/components/cronet/android/test/javatests/src/org/chromium/net/CronetTestBase.java
[modify] https://crrev.com/8f8aa43973e496a65d9eecfa3e6f8b8dd68432e7/components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestTest.java
[modify] https://crrev.com/8f8aa43973e496a65d9eecfa3e6f8b8dd68432e7/components/cronet/android/test/javatests/src/org/chromium/net/UploadDataProvidersTest.java

Labels: Merge-Request-60
I think we should put this in next week's Android dev channel release.
Project Member

Comment 5 by sheriffbot@chromium.org, Jun 1 2017

Labels: -Merge-Request-60 Hotlist-Merge-Approved Merge-Approved-60
Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 6 by bugdroid1@chromium.org, Jun 1 2017

Labels: -merge-approved-60 merge-merged-3112
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8a145da80cb326dca497d43777003498ac38e2a4

commit 8a145da80cb326dca497d43777003498ac38e2a4
Author: Paul Jensen <pauljensen@google.com>
Date: Thu Jun 01 13:05:27 2017

[Cronet]  Fix two races/leaks in JavaUrlRequest

The underlying InputStream and HttpURLConnection were accessed on different
threads which during cancellation could result in races resulting in leaks
that StrictMode catches. Shift all accesses to these variables to one
thread like the Chromium threading principles recommends.

BUG= 726193 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester

Review-Url: https://codereview.chromium.org/2903193002
Cr-Original-Commit-Position: refs/heads/master@{#475945}
Review-Url: https://codereview.chromium.org/2915033002 .
Cr-Commit-Position: refs/branch-heads/3112@{#87}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/8a145da80cb326dca497d43777003498ac38e2a4/components/cronet/android/java/src/org/chromium/net/impl/JavaUrlRequest.java
[modify] https://crrev.com/8a145da80cb326dca497d43777003498ac38e2a4/components/cronet/android/test/javatests/src/org/chromium/net/CronetTestBase.java
[modify] https://crrev.com/8a145da80cb326dca497d43777003498ac38e2a4/components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestTest.java
[modify] https://crrev.com/8a145da80cb326dca497d43777003498ac38e2a4/components/cronet/android/test/javatests/src/org/chromium/net/UploadDataProvidersTest.java

Status: Fixed (was: Started)

Sign in to add a comment