1778144 - OOM when specifying large `first` index for drawArrays

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect, P1)

Description

[Jason Kratzer [:jkratzer]]

Attachment: testcase.html

When passing a large value to the drawArrays first parameter, an OOM occurs. Chrome does not appear to be affected by this issue.

This issue is currently blocking fuzzing. Is it possible to make this allocation fallible or first check if the value is sane before attempting to allocate such a large buffer?

Comment 1

[Jason Kratzer [:jkratzer]]

Attachment: Firefox memory usage

Comment 2

[Jason Kratzer [:jkratzer]]

Attachment: Chrome memory usage

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:aosmond, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Kelsey Gilbert [:jgilbert]]

Ah, yeah, we're polyfilling no-attrib-arrays with attrib-arrays, and for correctness we can't naively just skip to first and only alloc count. (it gets particularly tricky once you add in instance divisor handling)
It would be reasonable to pick some upper bound like 10M verts (10M*4*4=160MB) and just claim OOM for more than that.

Comment 5

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1778144 - Add limit webgl.fake-verts.max=10M.

Otherwise seemingly lightweight but unusual calls like
drawArrays(offset:1.5billion) will try to allocate a very large gpu
buffer, which sometimes takes a very long time.

This is unusual and we shouldn't encourage it, so let's just add a
limit. 10M is 160MB, which is generally big enough but not too big.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d481929dba88
Add limit webgl.fake-verts.max=10M. r=gfx-reviewers,lsalzman

Comment 7

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/d481929dba88