Move attachment services check out of the FILE thread.
Reported by
1e...@realityexists.net,
Jun 30 2016
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Steps to reproduce the problem: 1. Have NOD32 real-time scanning enabled or another real-time virus scanner installed that scans .iso files, but not .crdownload files 2. Download a large ISO file, e.g. http://download.microsoft.com/download/1/2/1/1211d9dd-b504-47f2-90f2-20cb8b44e096/vs2015.2.ent_enu.iso 3. Wait for the download to complete and the file to be renamed to .iso What is the expected behavior? Chrome continues working as normal What went wrong? No tabs load. I can open a new tab and enter a URL and the status bar says "Waiting for (URL)", but the page does not load, regardless of the URL. After a while the "unresponsive page" dialog appears asking whether I wish to wait or kill the page. The same happens if I try to reload an existing tab. However I can still scroll through an already-loaded tab. Chrome still shows the download as being in progress, downloading at 0 bytes/sec for another 30-40 minutes. If I try to close Chrome during this time it prompts to me cancel or continue the download. The behaviour above continues as long as the download appears to be in-progress. As soon as it finally "completes" Chrome goes back to working as normal. Did this work before? N/A Chrome version: 51.0.2704.103 Channel: stable OS Version: 6.1 (Windows 7) Flash Version: Shockwave Flash 22.0 r0 I have NOD32 anti-virus installed with real-time scanning enabled. I believe what's happening is that when Chrome tries renames .crdownload file to it's proper extension (.iso in my case) the virus-scanner takes a very long time to scan it. That's fine, but Chrome should still be usable during this time. Also, it incorrectly reports that exiting Chrome will "cancel" the download. In fact, the file has downloaded, its SHA1 sum is correct and I can open and use it.
,
Jul 1 2016
,
Jul 5 2016
I *think* this is the IAttachmentExecute::Save() step that's taking this long. We can tell for certain if we had a net-internals log (https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details). When all the bytes for a file have been downloaded, Chrome attempts to "hand over" the file to the OS by invoking an API called Windows Attachment Services. This handover involves invoking all registered AV products to scan the newly saved file. This may take a while as it is the case here. The scan itself is being done on the FILE thread. We shouldn't do that because all other subsystems that rely on the FILE thread is going to block on the AV scan. I filed Issue 625856 for this. Other than that, we can improve the UX including reporting what will happen if the download were to be cancelled.
,
Jul 5 2016
Here you go. This log shows the end of downloading a 1.4 GB ISO file. Then, while the file is in "limbo" (all downloaded, but not shown as completed) I tried to browse to google.fr and the page did not load until after the ISO file finished downloading (about 10 seconds later).
,
Oct 3 2016
Thank you for the log and sorry about the delay. The log confirms my suspicion that the annotation step which invokes IAttachmentExecute::Save() is the one that is taking up the extra time. I'll fold issue 625856 into this issue since we've confirmed the root cause. We now need to move this check out of the FILE thread and improve the UI to indicate what's going on. During the annotation step (which is the one taking a long time), Chrome hands the file over to Windows and invokes AttachmentServices. Windows then invokes any registered AV programs to scan the file. This is likely going to take a long time for a large download like your ISO file. There's not much Chrome can do to speed things along here since things are out of Chrome's hands at this point. We can, however, prevent this work from interfering with the rest of the browser and improve the UI.
,
Oct 3 2016
Issue 625856 has been merged into this issue.
,
Oct 7 2016
,
Oct 9 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 19 2017
,
Mar 29 2018
There doesn't seem too much chrome can do, closing this for now |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by msrchandra@chromium.org
, Jul 1 2016