Unable to reproduce this issue on reported version 64.0.3282.186 using Ubuntu 14.04 with steps mentioned below.

1. Opened https://jsfiddle.net/0b0jzssr/30/ , opened task manager and observed memory footprint of this tab.
2. Uploaded file and observed increase in memory usage.
3. After sometime memory of that tab becomes normal in task manager.

@Reporter: Please check the video and let us know if we miss anything. Also please check the issue on fresh profile which do not have any apps/extensions. This info would help in further triaging of the issue.

Thanks!

Deleted: 817282.ogv 7.2 MB

	817282.ogv 7.2 MB View Download

sindhu.chelamcherla@ you need to choose a folder that contains large files (not in sub-folders) with a total size of 100-500MB for easier assessment.

FWIW in Windows I can reproduce with old Chrome/Chromium (51-60).
Bisected to r380607 (breakage) with a fix in 502c6ae6a03979efbd3e006e6a0b8c3369ca2bbc.
However, I didn't test in Linux so this may be a different regression.

I don't know why you can't reproduce, I think we are doing the same thing.

Deleted: out-7.ogv 3.0 MB

	out-7.ogv 3.0 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

https://jsfiddle.net/0b0jzssr/38/ -> JSFiddle with comment

Here is the expected comportement on Chromium

Deleted: out-2.ogv 3.1 MB

	out-2.ogv 3.1 MB View Download

As per comment #3, the issue seems to exist from M-60. Hence, marking it as untriaged for further inputs from dev team.

Thanks...!!

I'm not sure if this is WAI or not - the garbage collector doesn't necessarily remove stuff. We tell V8 about external blob memory I believe.

See here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fileapi/FileReaderLoader.cpp?dr=CSs&l=342

AdjustReportedMemoryUsageToV8

+mek

*the garbage collector doesn't necessarily remove stuff right away*

Does your system have a lot of memory?

After a chat with mek@, it seems like the FileReaderLoader is holding a reference to the ArrayBuffer, but Oilpan has no way of accessing / accounting for that object. We don't count it as 'external' memory either. Not sure the best way to solve this, but I think we've confirmed this as an issue.

possible ways of solving this:
- make FileReaderLoader garbage collected (and change every place that owns one from std::unique_ptr to Member, and add tracing etc).

- make FileReaderLoader DISALLOW_NEW, and change every place that owns one to just directly hold one rather than having a pointer. Only non-straightforward case I think would be IDBRequestLoader, where we'd then have to wrap the FileReaderLoader in something else. Every other usage I can find lifetime of the FileReaderLoader already seems to match lifetime of its owner.

- Refactor FileReaderLoader to not actually hold on to any memory past the load operation. Instead just transfer ownership of the resulting data to the client in DidFinishLoading.

- Probable other options exist as well...