New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 754544 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Error before sending parallel requests should block the requests

Project Member Reported by xingliu@chromium.org, Aug 11 2017

Issue description

Download service may hit  
DCHECK_LE(initial_request_offset_, first_slice_offset);
in parallel_download_job.cc.

This is because an IO thread error occur after we send the initial request, but before we send parallel request.

Before sending parallel requests, we should check if there is error in download item.
 
Labels: M61
Labels: -OS-All OS-Android
Labels: -M61 M-61
Cc: dtrainor@chromium.org qin...@chromium.org
Project Member

Comment 5 by bugdroid1@chromium.org, Aug 11 2017

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

commit 0f2c5ddcaba532562888e6effb626c64b9064b4b
Author: Xing Liu <xingliu@chromium.org>
Date: Fri Aug 11 18:04:26 2017

Fix a bug that IO thread error should block parallel requests.

We send parallel requests after sending the initial request and
initializing download file.

However, an IO thread error may occur during download resumption between
file initialized and building parallel request, we should check this
error, or may hit the following DCHECK:
DCHECK_LE(initial_request_offset_, first_slice_offset);
Because we clear |received_slices_| in DownloadItemImpl::Start when
interrupt reason is not none.

Bug:  754544 , 736046
Change-Id: I2d15469bb787411b5ecdeb0f40028f5527574c9f
Reviewed-on: https://chromium-review.googlesource.com/611609
Reviewed-by: David Trainor <dtrainor@chromium.org>
Commit-Queue: Xing Liu <xingliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493808}
[modify] https://crrev.com/0f2c5ddcaba532562888e6effb626c64b9064b4b/content/browser/download/parallel_download_job.cc
[modify] https://crrev.com/0f2c5ddcaba532562888e6effb626c64b9064b4b/content/browser/download/parallel_download_job_unittest.cc

Labels: Merge-Request-61
Project Member

Comment 7 by sheriffbot@chromium.org, Aug 11 2017

Labels: -Merge-Request-61 Merge-Review-61 Hotlist-Merge-Review
This bug requires manual review: M61 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: amineer@chromium.org
+amineer@, this bug may result in creating unexpected download requests, and may break download resumption, PTAL.

The fix is fairly small.


Labels: -Merge-Review-61 Merge-Approved-61
Merge approved for M61 branch 3163.  Please merge by EOD today.  Thanks!
Project Member

Comment 10 by bugdroid1@chromium.org, Aug 14 2017

Labels: -merge-approved-61 merge-merged-3163
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e6afef8c84d9fbf272a60a9815c10130272fd736

commit e6afef8c84d9fbf272a60a9815c10130272fd736
Author: Xing Liu <xingliu@chromium.org>
Date: Mon Aug 14 17:08:53 2017

Fix a bug that IO thread error should block parallel requests.

We send parallel requests after sending the initial request and
initializing download file.

However, an IO thread error may occur during download resumption between
file initialized and building parallel request, we should check this
error, or may hit the following DCHECK:
DCHECK_LE(initial_request_offset_, first_slice_offset);
Because we clear |received_slices_| in DownloadItemImpl::Start when
interrupt reason is not none.

TBR=xingliu@chromium.org

(cherry picked from commit 0f2c5ddcaba532562888e6effb626c64b9064b4b)

Bug:  754544 , 736046
Change-Id: I2d15469bb787411b5ecdeb0f40028f5527574c9f
Reviewed-on: https://chromium-review.googlesource.com/611609
Reviewed-by: David Trainor <dtrainor@chromium.org>
Commit-Queue: Xing Liu <xingliu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#493808}
Reviewed-on: https://chromium-review.googlesource.com/613669
Reviewed-by: Xing Liu <xingliu@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#527}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/e6afef8c84d9fbf272a60a9815c10130272fd736/content/browser/download/parallel_download_job.cc
[modify] https://crrev.com/e6afef8c84d9fbf272a60a9815c10130272fd736/content/browser/download/parallel_download_job_unittest.cc

Since this CL is not serve regression that impacts the users, and its unit test uses something not included in M61, I probably won't reland it to M61.
I'm confused by c#12, if this isn't that important why did we merge request it in the first place?
Sorry I probably shouldn't merge it as the first place.

It is a bug, that may create additional requests, but all the additional requests should also failed. It shouldn't change the user experience.

But I'm not sure if this bug may result in more serious issue, like file corruption.


Status: Fixed (was: Assigned)

Sign in to add a comment