New issue
Advanced search Search tips

Issue 719891 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocked on:
issue 712693



Sign in to add a comment

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 description

UserAgent: 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)
 
Components: Blink>Storage
Labels: M-57

Comment 2 by jsb...@chromium.org, May 18 2017

Cc: dmu...@chromium.org

Comment 3 by jsb...@chromium.org, May 18 2017

Components: -Blink>Storage Blink>FileAPI

Comment 4 by jsb...@chromium.org, 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)

Yes, it's reproducible with the console closed, even if I ran it in kiosk mode. 

Comment 6 by dmu...@chromium.org, 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
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? 

Comment 8 by dmu...@chromium.org, 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.

Comment 9 by jsb...@chromium.org, May 23 2017

Cc: -dmu...@chromium.org
Owner: dmu...@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 10 by mek@chromium.org, Feb 13 2018

Blockedon: 712693
Components: Blink>Storage>FileAPI
Components: -Blink>FileAPI
Cc: dmu...@chromium.org
Labels: Needs-Feedback
Owner: ----
Status: Available (was: Assigned)

Sign in to add a comment