Could you please capture a NetLog dump and post it here according to the instructions at https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details ?  Thank you.

The issue is occurring in Nexus device too in chrome 59.x version while trying to download a file. It's getting paused in between.

Thank you for providing more feedback. Adding requester "bnc@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Logs for S8 has been shared to bnc@chromium.org through google drive by midridgeyoon@samsung.com

Thank you.

If the current triager wants to take a look, contact me for the logs.  Otherwise I'll take a look as time permits.

Can we get the update on this issue.

It looks like this issue is a regression since M58, and is considered a critical issue for us.
Please let us know if there are any updates on the issue.
Thank you!

Also, could you please add jaehun.rhee@samsung.com, mili.adlakha@samsung.com, and ajay.sh@samsung.com to the CC list?

cc-ing Asanka, the download expert, for an extra set of eyes.

In event 1561, I see the following right after file size exceeds 2 GiB:

t=1410423 [st=1394787]  DOWNLOAD_ITEM_UPDATED
                        --> bytes_so_far = "2146581273"
t=1410923 [st=1395287]  DOWNLOAD_ITEM_UPDATED
                        --> bytes_so_far = "2146961902"
t=1411425 [st=1395789]  DOWNLOAD_ITEM_UPDATED
                        --> bytes_so_far = "2147413915"
t=1411576 [st=1395940]  DOWNLOAD_ITEM_UPDATED
                        --> bytes_so_far = "2147512379"
t=1411632 [st=1395996]  DOWNLOAD_ITEM_INTERRUPTED
                        --> bytes_so_far = "0"
                        --> interrupt_reason = "FILE_FAILED"
t=1411632 [st=1395996] -DOWNLOAD_ITEM_ACTIVE
t=1420931 [st=1405295]  DOWNLOAD_ITEM_RESUMED
                        --> bytes_so_far = "0"
                        --> interrupt_reason = "FILE_FAILED"
                        --> user_initiated = "false"
t=1421018 [st=1405382]  DOWNLOAD_FILE_CREATED
                        --> source_dependency = 3467 (DOWNLOAD_FILE)
t=1421019 [st=1405383] +DOWNLOAD_ITEM_ACTIVE  [dt=11551+]
                        --> danger_type = "NOT_DANGEROUS"
                        --> file_name = "5.5G.zip"
                        --> final_url = "http://192.168.0.107/5.5G.zip"
                        --> has_user_gesture = true
                        --> id = "1"
                        --> original_url = "http://192.168.0.107/5.5G.zip"
                        --> start_offset = "0"
                        --> type = "NEW_DOWNLOAD"
t=1421021 [st=1405385]    DOWNLOAD_ITEM_UPDATED
                          --> bytes_so_far = "0"
t=1421049 [st=1405413]    DOWNLOAD_ITEM_RENAMED
                          --> new_filename = "/storage/emulated/0/Download/5.5G.zip.crdownload"
                          --> old_filename = ""
t=1421652 [st=1406016]    DOWNLOAD_ITEM_UPDATED
                          --> bytes_so_far = "622880"
t=1422153 [st=1406517]    DOWNLOAD_ITEM_UPDATED
                          --> bytes_so_far = "966508"

"FILE FAILED" corresponds to "Generic file operation failure.  File Error." according to download_interrupt_reason_values.h.  This might be due to the limitation of the underlying filesystem: maybe it does not support files in excess of 2 GiB?  Are you by any chance trying to save on a FAT32 partition without LFS?

- Network.

bnc: There should be another event stream for DOWNLOAD_FILE. That stream should have the OS specific error code that was encountered during the write() call. Either way, it sounds like the error is not in network.

Thank you for your help.  Indeed here it is:

t=1411337 [st=1395815]  DOWNLOAD_FILE_WRITTEN  [dt=1]
                        --> bytes = "32768"
t=1411339 [st=1395817]  DOWNLOAD_STREAM_DRAINED
                        --> num_buffers = 3
                        --> stream_size = 35808
t=1411458 [st=1395936]  DOWNLOAD_FILE_WRITTEN  [dt=3]
                        --> bytes = "17912"
t=1411462 [st=1395940]  DOWNLOAD_FILE_WRITTEN  [dt=0]
                        --> bytes = "7240"
t=1411462 [st=1395940]  DOWNLOAD_FILE_WRITTEN  [dt=1]
                        --> bytes = "5792"
t=1411463 [st=1395941]  DOWNLOAD_FILE_WRITTEN  [dt=0]
                        --> bytes = "2896"
t=1411463 [st=1395941]  DOWNLOAD_FILE_WRITTEN  [dt=1]
                        --> bytes = "8688"
t=1411464 [st=1395942]  DOWNLOAD_STREAM_DRAINED
                        --> num_buffers = 5
                        --> stream_size = 42528
t=1411472 [st=1395950]  DOWNLOAD_FILE_WRITTEN  [dt=1]
                        --> bytes = "11584"
t=1411473 [st=1395951]  DOWNLOAD_FILE_WRITTEN  [dt=0]
                        --> bytes = "2896"
t=1411473 [st=1395951]  DOWNLOAD_FILE_WRITTEN  [dt=1]
                        --> bytes = "8688"
t=1411474 [st=1395952]  DOWNLOAD_FILE_WRITTEN  [dt=1]
                        --> bytes = "32768"
t=1411475 [st=1395953]  DOWNLOAD_STREAM_DRAINED
                        --> num_buffers = 4
                        --> stream_size = 55936
t=1411571 [st=1396049] +DOWNLOAD_FILE_WRITTEN  [dt=20999+]
t=1411572 [st=1396050]    DOWNLOAD_FILE_ERROR
                          --> interrupt_reason = "FILE_FAILED"
                          --> operation = "Write"
                          --> os_error = 22
t=1411610 [st=1396088]   -DOWNLOAD_FILE_OPENED
t=1411613 [st=1396091]    DOWNLOAD_STREAM_DRAINED
                          --> num_buffers = 1
                          --> stream_size = 23122
t=1411624 [st=1396102]    CANCELLED
t=1411624 [st=1396102]    DOWNLOAD_FILE_DELETED
t=1414766 [st=1399244]    DOWNLOAD_FILE_DETACHED
t=1414766 [st=1399244]   -DOWNLOAD_FILE_ACTIVE

OP: What's the target file system? It looks like you are getting an EINVAL for the write() call. (Assuming the logs are from an Android device despite the bug label of +Windows).

Also, can you clarify why you think this was a regression? Does it work when you try it with a M58 build?

I'm setting the status to Untriaged so that the downloads folks can have a look.

From our internal testing result, the issue is not reproducible when tested on M57, and we noticed that the issue is observed beginning from M58.

Changing the OS to Android.

Please let us know if there is any additional information needed for this issue.

#15: What's the underlying file system? (Just for completeness. It may not be relevant if this is a Chrome regression).

Either way, according to the log, the error occurred during the write() call, which implies that this is an interaction between Chrome and the filesystem *after* crossing the 2GiB boundary.

+dtrainor for downloads.

@mili.adlakha, could you please check the question from @asanka?

Also, can you try a current stable with a fresh profile? One where the download is the first thing you do.

Removing "Restrict-View-Google" text from issue title, since issue is not labeled as such, to prevent confusion.

Can you also let us know which Android OS version you're running this on and respond to #16 and #18?  That would help us track this down.  Thanks for your help!

Android version : 7.1.1

Reply : comment #16 :
I discussed internally with the FileSystem here and according to them,
there is no file system limitation regarding 2GiB size, including FAT32 and ext4 or other Linux file systems.
Even on FAT32, its limitation is 4GB for maximum file size and it only used for external storages like SD Cards or USB memory sticks

Reply: comment #18 :
Yes we tried the first thing after doing the factory reset and the downloading was paused. Just updated the Chrome version to 59.x from playstore and it paused too.
We tried under different scenarios and with different devices as well.
Preloaded 57.x version  -> PASS
Update to 58.x, 59.x on the same device -> FAIL

Preloaded 58.x version -> FAIL

Tried on Nexus : FAIL

Please let us know if further information is required from my end.

To support parallel downloading, Chrome switches to use pwrite(int fd, const void *buf, size_t count, off_t offset) so that it can write to an arbitrary file location.
However, off_t is a signed integer, so it overflows when reaching 2GB. We should use pwrite64 instead.

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

commit 46d636d25e054da0b0d8270d525c84f39146ce30
Author: Min Qin <qinmin@chromium.org>
Date: Thu Jul 20 01:10:30 2017

use pwrite64() instead of pwrite() when writing to file on Android

The offset param for File::Write() is int64_t.
However, pwrite() takes a signed integer for offset.
As a result, File::Write() will not work for offset larger than 2GB.
Change to pwrite64() so it will work on 32bit legacy systems.
This issue is not present on Linux because __USE_FILE_OFFSET64 is set.

BUG= 739587 

Change-Id: I357488b95cd6c501a9f9547ff220f86ef069dc3b
Reviewed-on: https://chromium-review.googlesource.com/578290
Commit-Queue: Min Qin <qinmin@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488073}
[modify] https://crrev.com/46d636d25e054da0b0d8270d525c84f39146ce30/base/os_compat_android.h

Will the above change be applied to M61?

This CL is included in M61.  i am also requesting it to be merged into M60 as this is a pretty serious issue

This bug requires manual review: We are only 4 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

qinmin@, this is super late to be merging changes to M60 - we're only taking changes for critical stuff, does this qualify since it's been broken since ~M58?  Does it only occur on super large files e.g. those > 2GB?  Is the CL super safe and can you give me 99% confident it won't break anything?

Checking the UMA, less than 0.01% of the download are larger than 2GB on M57, and we don't have any download larger than 2GB in M58 and M59 due to this bug.

I am ok we don't merge this to M60 since the >2GB downloads are really rare

Rejecting per c#29, thanks.

Hello
We are facing this issue again.
We did overnight testing and tried to download a file more than 2.5Gb from speed.hetzner.de. 
Downloading paused in between.
Testing has been done on latest chrome version(66.0.3359.158)

Please find the attached bugreport

Deleted: log.zip 8.1 MB

log.zip 8.1 MB Download

Steps to reproduce the problem:
1) Open Chrome
2) Open website speed.hetzner.de
3) Download a file of more than 2.5GB
4) Observe

What is the expected behavior?
1) Downloading should be completed in one go without pausing.

What went wrong?
Downloading paused in between.

Chrome version: 66.0.3359.158  Channel: stable

We have tested the issue at our end and it's still occurring on 66.0.3359.158 and on Chrome Beta 67.0.3396.29, with the steps mentioned above.

This seems to be the probable cause for the same.
As, the issue was fixed in chrome version 61 by adding the below patch 
// In case __USE_FILE_OFFSET64 is not used, we need to call pwrite64() instead
// of pwrite()
#define pwrite(fd, buf, count, offset) pwrite64(fd, buf, count, offset)

But, the patch has been reverted for the later versions of chrome
Change-Id: I643f9f7bd75d111e540778d2fdf8c20851485a5a
Reviewed-on: https://chromium-review.googlesource.com/777822

Note : Downloading is getting failed in Pixel too.
Also, issue reproduced using HFS(http file server).
Attaching the net-export logs for reference.

Deleted: chrome-net-export-log.zip 2.2 MB

chrome-net-export-log.zip 2.2 MB Download

Thank you for pinpointing the root cause.  I'm assinging this issue to the original author of https://crrev.com/c/578290 (already owner, just changing status from Available to Assigned).  Given the motivation of https://crrev.com/c/777822, however, I am not sure if this is trivial to fix again at this point.

Min can you take a look and work with bsheedy@ to get the fix back in?

fix already landed https://chromium-review.googlesource.com/c/chromium/src/+/1081608