Another site that this seems to happen under hdfilme.tv

Just realized this affects the Android System WebView 64 as well on Android 5+

I could reproduce this locally, I see a lot of the following errors, could they be related?

01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: java.net.SocketTimeoutException: Read timed out
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at java.net.SocketInputStream.socketRead0(Native Method)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at java.net.SocketInputStream.socketRead(SocketInputStream.java:119)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at java.net.SocketInputStream.read(SocketInputStream.java:176)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at java.net.SocketInputStream.read(SocketInputStream.java:144)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at java.io.BufferedInputStream.fill(BufferedInputStream.java:248)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at java.io.BufferedInputStream.read(BufferedInputStream.java:267)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at java.io.FilterInputStream.read(FilterInputStream.java:83)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at sunlabs.brazil.util.http.HttpInputStream.readLine(HttpInputStream.java:153)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at sunlabs.brazil.util.http.HttpInputStream.readLine(HttpInputStream.java:128)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at sunlabs.brazil.server.Request.getRequest(Request.java:759)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at sunlabs.brazil.server.Connection.run(Connection.java:186)
01-29 11:18:25.931 20522 21289 W sunlabs.brazil.server.Connection: 	at java.lang.Thread.run(Thread.java:764)

Those are fairly normal errors, often unrelated to the webview, sometimes ad network stuff or other things the app is doing, but even when webview related, they don't freeze the app. It only started freezing on version version 64. 

Thank you for providing more feedback. Adding requester "gsennton@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I'm not sure how to debug ANRs, Bo/Toby do you have any suggestions?

An alternative would be perform a bisection.

after the ANR dialog comes up, attach the traces.txt file here:
adb pull /data/anr/traces.txt

Was comment 8 for me or someone else?

that was reply to #7, but anyone who can reproduce this can do it

In that directory I only have a file called anr_2018-01-30-14-08-59-704 but when I try to pull it it says permission denied. My phone is not rooted. 

Not sure about root, but I have seen devices where that file isn't globally writable, which breaks this debug feature. Nexus/pixel should be ok though. It's supposed to be stacks of every jvm attached thread. Very useful to find where a the UI thread is hanging

This is on a Pixel XL. Do I have to enable something on developer settings?

Alas, you do need root :/
https://developer.android.com/topic/performance/vitals/anr.html#diagnosing_anrs

If you take a bugreport, it should contain the same info (and a lot more, including a lot more user-private things). Need the "VM TRACES AT LAST ANR" section.

Hope this is what you need. 

Deleted: traces at anr.txt 285 KB

traces at anr.txt 285 KB View Download

hmm, probably stuck in the synchronous IPC to the compositor thread. definitely worth investigating 

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x739b5610 self=0x7c2e6bea00
  | sysTid=3152 nice=-4 cgrp=default sched=0/0 handle=0x7cb32369a8
  | state=S schedstat=( 3240832805 2268822798 4513 ) utm=292 stm=31 core=0 HZ=100
  | stack=0x7fdd622000-0x7fdd624000 stackSize=8MB
  | held mutexes=
  kernel: __switch_to+0x88/0xbc
  kernel: futex_wait_queue_me+0xdc/0x168
  kernel: futex_wait+0xf4/0x21c
  kernel: do_futex+0x16c/0xb3c
  kernel: SyS_futex+0x98/0x1b0
  kernel: __sys_trace_return+0x0/0x4
  native: #00 pc 000000000001d82c  /system/lib64/libc.so (syscall+28)
  native: #01 pc 000000000006930c  /system/lib64/libc.so (pthread_cond_wait+96)
  native: #02 pc 00000000007afdf8  /data/app/com.chrome.beta-nPuxuRnSi-44Oo77vY2KjA==/base.apk (???)
  at org.chromium.ui.base.WindowAndroid.nativeOnVSync(Native method)
  at org.chromium.ui.base.WindowAndroid.access$700(WindowAndroid.java:134)
  at org.chromium.ui.base.WindowAndroid$1.onVSync$5166USJ75THMGSJFDLKNAR9FELKIULIJF5N66JBFDPKN8RRI7D52ILG_0(WindowAndroid.java:16)
  at org.chromium.ui.VSyncMonitor$1.doFrame(VSyncMonitor.java:22)
  at android.view.Choreographer$CallbackRecord.run(Choreographer.java:909)
  at android.view.Choreographer.doCallbacks(Choreographer.java:723)
  at android.view.Choreographer.doFrame(Choreographer.java:655)
  at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:897)
  at android.os.Handler.handleCallback(Handler.java:790)
  at android.os.Handler.dispatchMessage(Handler.java:99)
  at android.os.Looper.loop(Looper.java:164)
  at android.app.ActivityThread.main(ActivityThread.java:6494)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)

Ahh, the IO thread is hanging in some http cache thing. And a hanging IO thread just stops everything

A debug build earlier triggered a bunch of DCHECK crashes in that code earlier which I thought wasn't important. Doesn't seem to happen on chrome though, which is a bit odd.

This is the hanging stack I got when DCHECKs are disabled:

"Chrome_IOThread" prio=7 tid=61 Native
  | group="main" sCount=1 dsCount=0 obj=0x132130a0 self=0x9d5b0b00
  | sysTid=13562 nice=-4 cgrp=default sched=0/0 handle=0x8c443930
  | state=R schedstat=( 6780957311 279643580 5522 ) utm=671 stm=7 core=1 HZ=100
  | stack=0x8c347000-0x8c349000 stackSize=1014KB
  | held mutexes=
  native: #00 pc 000837fa  /data/app/com.google.android.webview-2/lib/arm/libnet.cr.so (_ZN3net9HttpCache11Transaction6DoLoopEi+485)
  native: #01 pc 00083ab1  /data/app/com.google.android.webview-2/lib/arm/libnet.cr.so (_ZN3net9HttpCache11Transaction4ReadEPNS_8IOBufferEiRKN4base17RepeatingCallbackIFviEEE+90)
  native: #02 pc 0012bcc3  /data/app/com.google.android.webview-2/lib/arm/libnet.cr.so (_ZN3net17URLRequestHttpJob11ReadRawDataEPNS_8IOBufferEi+54)
  native: #03 pc 0012cd1b  /data/app/com.google.android.webview-2/lib/arm/libnet.cr.so (_ZN3net13URLRequestJob17ReadRawDataHelperEPNS_8IOBufferEiRKN4base17RepeatingCallbackIFviEEE+30)
  native: #04 pc 0012c58d  /data/app/com.google.android.webview-2/lib/arm/libnet.cr.so (_ZN3net13URLRequestJob4ReadEPNS_8IOBufferEi+84)
  native: #05 pc 0012775d  /data/app/com.google.android.webview-2/lib/arm/libnet.cr.so (_ZN3net10URLRequest4ReadEPNS_8IOBufferEi+42)
  native: #06 pc 0027d4f3  /data/app/com.google.android.webview-2/lib/arm/libcontent.cr.so (_ZN7content14ResourceLoader8ReadMoreEb+22)
  native: #07 pc 0027d691  /data/app/com.google.android.webview-2/lib/arm/libcontent.cr.so (_ZN7content14ResourceLoader17PrepareToReadMoreEb+100)
  native: #08 pc 0027d611  /data/app/com.google.android.webview-2/lib/arm/libcontent.cr.so (_ZN7content14ResourceLoader13ResumeReadingEv+120)
  native: #09 pc 00012a97  /data/app/com.google.android.webview-2/lib/arm/libbase.cr.so (_ZN4base5debug13TaskAnnotator7RunTaskEPKcPNS_11PendingTaskE+98)
  native: #10 pc 0002758f  /data/app/com.google.android.webview-2/lib/arm/libbase.cr.so (_ZN4base11MessageLoop7RunTaskEPNS_11PendingTaskE+306)
  native: #11 pc 000278fb  /data/app/com.google.android.webview-2/lib/arm/libbase.cr.so (_ZN4base11MessageLoop6DoWorkEv+258)
  native: #12 pc 00028a51  /data/app/com.google.android.webview-2/lib/arm/libbase.cr.so (_ZN4base19MessagePumpLibevent3RunEPNS_11MessagePump8DelegateE+276)
  native: #13 pc 0003dac1  /data/app/com.google.android.webview-2/lib/arm/libbase.cr.so (_ZN4base7RunLoop3RunEv+42)
  native: #14 pc 001a258d  /data/app/com.google.android.webview-2/lib/arm/libcontent.cr.so (_ZN7content17BrowserThreadImpl11IOThreadRunEPN4base7RunLoopE+8)
  native: #15 pc 001a2673  /data/app/com.google.android.webview-2/lib/arm/libcontent.cr.so (_ZN7content17BrowserThreadImpl3RunEPN4base7RunLoopE+182)
  native: #16 pc 00060717  /data/app/com.google.android.webview-2/lib/arm/libbase.cr.so (_ZN4base6Thread10ThreadMainEv+182)
  native: #17 pc 0005c69f  /data/app/com.google.android.webview-2/lib/arm/libbase.cr.so (???)
  native: #18 pc 0003f45f  /system/lib/libc.so (_ZL15__pthread_startPv+30)
  native: #19 pc 00019b43  /system/lib/libc.so (__start_thread+6)
  (no managed stack frames)

The first DCHECK that failed was this:
https://cs.chromium.org/chromium/src/net/http/http_cache_transaction.cc?rcl=9b4b0badbfb6ffcd2fb57e1aa90ae9dd9e4c611b&l=398

+author and reviewers, relevant info in comment #17 above

Ping. And forgot to bump priority

 boliu@, Could you confirm what was the Chrome version used on getting the DCHECK and the error reproduced?
There have been a few fixes post the version mentioned in the bug description (64.0.3282.123) and it will be good to know if the issue is still coming in the latest Chrome version.

DCHECK error:
[FATAL:http_cache_transaction.cc(398)] Check failed: OK > shared_writing_error_ (0 vs. 0)

I'm building trunk right now: refs/heads/master@{#533271}

Do you believe this should be reproducible with Chrome (or Content shell), or is the standalone app needed? 

#23 I have only ever reproduced it with my app, not Chrome. 

I tired chrome on android stable release (64.0.3282.137, no DCHECKs obviously) on the same page and didn't see any issues.

I don't see any issues with just a simple webview wrapper app either, so must be that app only. Presumably has something to do webview's integration into the network stack for things like shouldInterceptRequest then.

I tried with Chromium build on trunk with DCHECKS enabled, but could not reproduce the issue. Both http://icdrama.se/hk-drama/2864-lo-and-behold/ and hdfilme.tv seem to be working fine. 

If I may give you some more insight into the issue. My app uses an http proxy. The issue only happens when using the proxy but only on Chrome/WebView 64. Does not happen on older WebView. 

Regarding comment #26: Just to confirm, does the dcheck happen with just a simple webview wrapper app but the ANR does not?

> My app uses an http proxy.

Oh, that sounds more likely to be related than shouldInterceptRequest then.

> Regarding comment #26: Just to confirm, does the dcheck happen with just a simple webview wrapper app but the ANR does not?

No DCHECK, no ANR with simple webview wrapper app

I do use shouldInterceptRequest heavily but I can leave shouldInterceptRequest alone and only disable the proxy and it works fine. The proxy alone seems to cause it. I just don't have any idea why, as far as I can tell I don't touch anything related to the WebView from the proxy code. 

 carlos@instantbits.com: Could you please get the net internal logs when the issue is coming. Here are the instructions to get them: 
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Just to be clear, I do this on chrome and then reproduce the issue on my app? Or do I somehow do this within my app?

shivanisha@, WebView doesn't have net-internals and can't capture logs that way (though I'm not sure if there's another way to get the same data).

When you are working on the app, is it possible to open another tab in the app with one tab with the affected site and another tab with net internals? I am assuming the app has a chrome like interface for tabs where you can open 2 URLs, one in each tab, I am not sure though.

Also, if your are able to get the net internals logs successfully, it would be good to get the logs with and without proxy to be able to compare them.

chrome:// URLs do not work in WebView at all unless specifically implemented as WebView features. If there's a way to get network logs it won't be something that's accessed via magic URLs; possibly with command line flags (which can only be used on debug builds of android, not user builds).

The command line flag to get netlogs is --log-net-log=/path/to/file
But it possibly wouldn't work in user build?

Don't know if the implementation of that is compiled into webview or not, but in any case webview ignores all command line flags on user builds of android, and only reads custom flags on userdebug/eng devices. The emulator is a userdebug image, so it may work there, but external users don't generally have debug images for real devices unless they run custom builds of android.

apparently it supposed to work with the command line:
https://chromium-review.googlesource.com/c/chromium/src/+/674084/6/android_webview/browser/net/aw_url_request_context_getter.cc

I'll see if it actually does..

I have a fix here: https://chromium-review.googlesource.com/c/chromium/src/+/896145

This is what seems to be happening in the error scenario (case with proxy).
There was an extra Read being invoked by the consumer of HttpCache::Transaction and the transaction state machine was not handling it well (crashing with dcheck/infinite loop in DoLoop if dcheck disabled). The CL fixes the handling.

netlog with DCHECK enabled, so no idea if it actually captured the actual problem

Deleted: netlog.json 324 KB

netlog.json 324 KB View Download

and without DCHECK, after ANR and killing the app, still not sure if it captured everything though I suppose, if there is no explicit flush of the file..

Deleted: netlog.json 332 KB

netlog.json 332 KB View Download

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

commit ecc43a2f3233d5c3189f6fc79c13aa5f714c9e4c
Author: Shivani Sharma <shivanisha@chromium.org>
Date: Thu Feb 01 16:30:32 2018

HttpCache::Transaction::Read should be able to handle an extra Read.

There was an extra Read being invoked by the consumer of
HttpCache::Transaction in some cases and the transaction state machine
was not handling it well (crashing with dcheck/infinite loop in DoLoop).
This CL fixes the handling.
Tested that the unit test indeed asserts without the fix if dcheck is
enabled (if not, the DoLoop will go in an infinite loop since we were
entering it with next_state_ set as STATE_NONE and then in the while
loop setting it as STATE_UNSET).

Test: net_unittests --gtest_filter=HttpCache.SimpleGET_ExtraRead
Bug:  806344 
Change-Id: I8b9472b48b15ed9f6c2132863f66941010b7aa52
Reviewed-on: https://chromium-review.googlesource.com/896145
Commit-Queue: Shivani Sharma <shivanisha@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533693}
[modify] https://crrev.com/ecc43a2f3233d5c3189f6fc79c13aa5f714c9e4c/net/http/http_cache_transaction.cc
[modify] https://crrev.com/ecc43a2f3233d5c3189f6fc79c13aa5f714c9e4c/net/http/http_cache_unittest.cc

Thank you for handling this so quickly. What version of chrome and webview should I see this fix? And how long might it take before they are released?

Thanks. 

[Auto-generated comment by a script] We noticed that this issue is targeted for M-65; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-65 label, otherwise remove Merge-TBD label. Thanks.

This will likely require merge to M65. As per process, will wait for the fix to be passed through either a Canary build or Dev channel release at least 24 hours and will then attach the merge label.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

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

commit 54d14bc56e841fbf7717c4934d6d24d90cbd86da
Author: Shivani Sharma <shivanisha@chromium.org>
Date: Mon Feb 05 15:42:59 2018

HttpCache::Transaction::Read should be able to handle an extra Read.

There was an extra Read being invoked by the consumer of
HttpCache::Transaction in some cases and the transaction state machine
was not handling it well (crashing with dcheck/infinite loop in DoLoop).
This CL fixes the handling.
Tested that the unit test indeed asserts without the fix if dcheck is
enabled (if not, the DoLoop will go in an infinite loop since we were
entering it with next_state_ set as STATE_NONE and then in the while
loop setting it as STATE_UNSET).

Test: net_unittests --gtest_filter=HttpCache.SimpleGET_ExtraRead
Bug:  806344 
Change-Id: I8b9472b48b15ed9f6c2132863f66941010b7aa52
Reviewed-on: https://chromium-review.googlesource.com/896145
Commit-Queue: Shivani Sharma <shivanisha@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533693}(cherry picked from commit ecc43a2f3233d5c3189f6fc79c13aa5f714c9e4c)
Reviewed-on: https://chromium-review.googlesource.com/901703
Reviewed-by: Shivani Sharma <shivanisha@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#297}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/54d14bc56e841fbf7717c4934d6d24d90cbd86da/net/http/http_cache_transaction.cc
[modify] https://crrev.com/54d14bc56e841fbf7717c4934d6d24d90cbd86da/net/http/http_cache_unittest.cc

Could not reproduce the issue mentioned in #1 on 64.0.3282.123 , 65.0.3325.53 66.0.3342.3 & having Pixel2/OPM1.171023.021 with Web Video Caster / 4.1.13 .