Using XMLHttpRequest to download large files in queue will fail after reaching 1.9GB of transferred data
Reported by
mzmras...@appspace.com,
May 9 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Platform: 9202.64.0 (Official Build) stable-channel panther Steps to reproduce the problem: Download the test Chrome App(https://www.dropbox.com/s/jo8mch0j76u6ell/xhr-request.crx?dl=0), install and launch it inside Chrome for ChromeOS 1. Open the debugger console, on network's tab, disable cache. 2. At the app, click on 'Start large files' and wait until the downloads finish (2000 times) What is the expected behavior? It should download the files repeatedly until it reaches 2000 times. What went wrong? - It would fail to download the files when it reached of total 1.9GB of transferred data. Did this work before? No Does this work in other browsers? N/A Chrome version: 57.0.2987.133 Channel: n/a OS Version: 57.0.2987.146 Flash Version: 1. The reason to disable cache is because, in our app, we will download the contents from a list that is not the same to each other. In this case, we found the issue on our customer end while downloading about 20 different large files (ranging from 200mb - 600mb) 2. We don't think it has to do with the size of the files. When tested with small files (10mb and 5mb) it will fail too after reaching around 1.9GB of total transferred data. 3. We thought that the garbage collector couldn't handle the xhr object we created (as stated here http://nullprogram.com/blog/2013/02/08/), so we make the xhr object global and nullified it whenever we start a new xhr request, but this would fail too (codes are in the main.js file) 4. This does not happen on chrome running on the desktop (Mac or Windows). Found that this only happens on ChromeOS (in this particular case, Asus Chromebox - https://www.amazon.com/Asus-CHROMEBOX-M004U-ASUS-Desktop/dp/B00IT1WJZQ)
,
May 18 2017
,
May 18 2017
,
May 22 2017
Are you able to repro the console closed? (It's easy to end up leaking blobs, e.g. logging to the console will result in a reference being held)
,
May 23 2017
Yes, it's reproducible with the console closed, even if I ran it in kiosk mode.
,
May 23 2017
This is because xhr blobs go into temp storage, which is gated to 2gb. I have a bug for moving this to the new blob storage folder - want to tackle that soon
,
May 23 2017
Hello! In our app we download pieces of data continuously - we process metadata and then we save content items into File system. Once cumulative size of the data downloaded over long time reaches 2 GB we start seeing failures. The point is that we don't need all the data after we've processed them, therefore they should be deallocated from temp storage. Your comment indicates that they are not deallocated. The question is then - is it our app which holds the reference and prevents GC from releasing it and subsequently freeing up temp storage i.e. leaking? - or is it chromium who does not even try to deallocate BLOBs from temp storage? Or can you suggest a way to check that?
,
May 23 2017
Can you check chrome://blob-internals when you see this issue? It lists all blobs, and you should be able to determine if they are being kept around.
,
May 23 2017
,
Feb 13 2018
,
Jun 15 2018
,
Jun 15 2018
,
Jan 3
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by rjahagir@chromium.org
, May 16 2017Labels: M-57