New issue
Advanced search Search tips

Issue 829146 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression

Blocked on:
issue 829410



Sign in to add a comment

net::ERR_INSUFFICIENT_RESOURCES error when loading ~10 MB large blob by XHR

Reported by bug.iss...@gmail.com, Apr 4 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3387.0 Safari/537.36

Steps to reproduce the problem:
The general structure for the XHR is:

var xhr = new XMLHttpRequest();
xhr.onload = function()
{
    if (xhr.status == 200)
    {
        var blob = xhr.response;
        // do something...
    }
};
xhr.open('GET', urlForLargeBlob, true);
xhr.responseType = 'blob';
xhr.send();

The mime-type for the response Content-Type header is application/octet-stream, and the returned blob is 10924129 bytes.

(There are also handlers defined for onerror, onabort, ontimeout, onprogress, and onloadend.)

What is the expected behavior?
No error during the XHR.

What went wrong?
Got error "Failed to load resource: net::ERR_INSUFFICIENT_RESOURCES".

Did this work before? Yes 

Does this work in other browsers? Yes

Chrome version: 67.0.3387.0  Channel: n/a
OS Version: 10.0
Flash Version: 

Workaround:
Set the response type to 'arraybuffer' instead of 'blob' and create a new Blob object from the response.

Worked with a Chromium build from this commit: https://chromium.googlesource.com/chromium/src/+/db579a7be98ed19502005f8ff27bce942cf393d4

Did not work with a Chromium build from this commit: https://chromium.googlesource.com/chromium/src/+/42cd4a84003a14c2098bc919534a912caaf86bce

It seems somewhere in between those commits, something broke it. This commit stands out: https://chromium.googlesource.com/chromium/src/+/090b1a4fea8bd71d2bd5e3503d3397985ad58022
 
Labels: Needs-Triage-M67

Comment 2 by woxxom@gmail.com, Apr 5 2018

Attaching a simplified test.html that displays SUCCESS or FAILURE.
Confirming the bisect range: 547242 (good) - 547257 (bad)
https://chromium.googlesource.com/chromium/src/+log/1f34e493..42cd4a84?pretty=fuller
Suspecting same.

test.html
429 bytes View Download
Cc: mek@chromium.org yhirano@chromium.org
Components: Blink>Network>XHR
Components: UI>Browser>Omnibox Services>Safebrowsing
Labels: -Pri-2 Triaged-ET RegressedIn-67 M-67 Target-67 FoundIn-67 hasbisect OS-Linux OS-Mac Pri-1
Owner: tommycli@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on reported version 67.0.3387.0 using Mac 10.12.6, Ubuntu 14.04 and Windows-10, hence providing Bisect Info and assigning to suspect from comment#2

Bisect Info:
================
Good build: 67.0.3384.0
Bad build: 67.0.3385.0

Change Log: https://chromium.googlesource.com/chromium/src/+log/67.0.3384.0..67.0.3385.0?pretty=fuller&n=10000
Commit: https://chromium.googlesource.com/chromium/src/+/42cd4a84003a14c2098bc919534a912caaf86bce

Change-Id: I4ca9bd292f53c897d2faf6d7d8a4faeb4dc1b18d
Reviewed-on: https://chromium-review.googlesource.com/986716

@Tommy C. Li: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable as it is seems a receent break, feel free to remove it if not applicable.

Thanks!

Comment 5 by woxxom@gmail.com, Apr 5 2018

No, the suspected CL from #c2 is same as reported originally: 090b1a4fea8bd71d2bd5e3503d3397985ad58022

Comment 6 by mek@chromium.org, Apr 5 2018

Components: -UI>Browser>Omnibox -Services>Safebrowsing Blink>Storage
Owner: mek@chromium.org
Hmm, seems to be something weird going on with how the blob system decides how much disk space it has available for blobs (and this is definitely caused by my CL)

Comment 7 by mek@chromium.org, Apr 5 2018

Well, it breaking XHR is caused by my CL. The blob system itself unfortunately was already broken, as it is never using more than 0 bytes of disk space (according to UMA histograms)

Comment 8 by mek@chromium.org, Apr 5 2018

Blockedon: 829410

Comment 9 by mek@chromium.org, Apr 23 2018

Status: Fixed (was: Assigned)
I believe this should be fixed with the bug it was blocked in being fixed.

Sign in to add a comment