New issue
Advanced search Search tips

Issue 814599 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

'Aw, Snap!' while loading large file using protobufjs

Reported by lutzroe...@gmail.com, Feb 22 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/604.5.6 (KHTML, like Gecko) Version/11.0.3 Safari/604.5.6

Steps to reproduce the problem:
1. Download https://docs-assets.developer.apple.com/coreml/models/VGG16.mlmodel
2. Open https://lutzroeder.github.io/Netron in Chromium/Chrome
3. Click ‘Open Model’ to open the .mlmodel file

What is the expected behavior?
Works in Edge, Safari, FireFox. The model opens and renders correctly.

What went wrong?
Chrome shows “Aw, Snap! Something went wrong while displaying this webpage”

Crashed report ID: 

How much crashed? Just one tab

Is it a problem with a plugin? No 

Did this work before? No 

Chrome version: Version 66.0.3352.0 (Developer Build) (64-bit)  Channel: n/a
OS Version: OS X 10.13.3
Flash Version:
 
Components: Blink
Labels: Target-67 M-67 OS-Windows
Status: Untriaged (was: Unconfirmed)
Tested this issue on Mac 10.13.3 ,Windows 7 using chrome latest stable-	64.0.3282.186 & Canary-67.0.3362.0 as per the above steps. Observed crash when we open .mlmodel file . Same issue observed from M60 builds to latest Canary. As it is non regression issue, marking it as Untriaged to get more inputs from dev.

Please find the attached screencast for reference.
Thanks..! 


814599-M60.mp4
1.4 MB View Download

Comment 2 by tkent@chromium.org, Mar 7 2018

Components: -Blink Blink>FileAPI
The file size is 500+ MB.
I guess FileReader consumes a lot of memory unexpectedly.

Comment 3 by mek@chromium.org, Mar 7 2018

Components: -Blink>FileAPI Blink
I don't think FileReader is to blame here. If you look at an actual stack trace for this crash (for example from crash/c5afa4bb13ae3747) you see that the OOM happens after the loading by FileReader has finished (FileReader also only does one allocation before loading starts, and shouldn't do any more allocations after that if the result is requested as an ArrayBuffer, which seems to be the case here.
Components: -Blink Blink>JavaScript
Cc: mlippautz@chromium.org
Owner: petermarshall@chromium.org
Status: Assigned (was: Untriaged)
To memory sheriff for further investigation.
We are hitting the hard limit for FixedDoubleArray size here: https://cs.chromium.org/chromium/src/v8/src/heap/heap.cc?l=3981&rcl=42dd0fcca27021a7c219e1a28b52107f95dd923e
with length = 75209227

A workaround would be to use a Float64Array, on 64-bit you should be able to allocate one up to length 268435456 (2^28).

We might also be able to increase the hard limit for FixedDoubleArray on 64-bit, given that the limit for FixedArray is already 2x larger: https://cs.chromium.org/chromium/src/v8/src/objects/fixed-array.h?l=156&rcl=42dd0fcca27021a7c219e1a28b52107f95dd923e


Cc: u...@chromium.org
cc Ulan because we talked about this on Friday
Project Member

Comment 8 by bugdroid1@chromium.org, Aug 3

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/842569eb4b5680f0fa7d8b85f8aa88cfbf23c3d5

commit 842569eb4b5680f0fa7d8b85f8aa88cfbf23c3d5
Author: Peter Marshall <petermarshall@chromium.org>
Date: Fri Aug 03 10:35:25 2018

[arrays] Increase max size of FixedDoubleArray by 2x on 64 bit

FixedArray max size is currently 1024 MB on 64 bit and 512 MB on 32 bit.
Update the max size of FixedDoubleArray to match. This doubles the max
size for arrays of doubles.

Bug: chromium:814599
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I3ac1b4caaf5b6428fe8a8c848fffdf84af8a9ae9
Reviewed-on: https://chromium-review.googlesource.com/1160235
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54892}
[modify] https://crrev.com/842569eb4b5680f0fa7d8b85f8aa88cfbf23c3d5/include/v8.h
[modify] https://crrev.com/842569eb4b5680f0fa7d8b85f8aa88cfbf23c3d5/src/objects/fixed-array.h

We will still think about further length increases - this will interact with pointer compression so we probably need to write a design doc.

Sign in to add a comment