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

Issue 899725 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
OOO until 2019-01-24
Closed: Nov 1
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

GLSL bug: undetected out of range vector/array indexing in loops

Reported by fabrice....@gmail.com, Oct 29

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36

Example URL:
https://www.shadertoy.com/view/4tcfDS

Steps to reproduce the problem:
access V[n] in a loop for V a vector or array and n out of range.

What is the expected behavior?
Either not compile (unrolled loops) or cause runtime error.

What went wrong?
No error if in a loop (even when unrolled),
while error if direct indexing.

Indeed the index is clamped to either the min or max legit value, even for a left-value (which might cause some bugs).
But this behavior occurs only if context is in a loop.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? No
 Firefox. Occuring both with Angle and OpenGL, Windows & Linux.

Chrome version: 70.0.3538.67  Channel: n/a
OS Version: 16.04
Flash Version: 

may somebody please add the flag Blink>WebGL ?

I'm not sure what the spec says about this, since
this is again a problem of behavior coherency between what is solved at compile time vs at run time (here, including unrolled loops).
 
Labels: Needs-Triage-M70
Components: -Blink Blink>WebGL
Owner: kbr@chromium.org
Status: WontFix (was: Unconfirmed)
There's no practical way to signal from a shader back to the host-side API that an out-of-range index access occurred. It's also not feasible to statically detect all sorts of potential out-of-range indexing, especially when the array indexing expression is complicated and involves loop indexes. For this reason WebGL defined the behavior of out-of-range accesses in the way described here:

https://www.khronos.org/registry/webgl/specs/latest/1.0/#4.5

The behavior here is exactly what's allowed by the spec. The out-of-range reads are clamped to within the array, and the out-of-range writes modify an unspecified area of storage accessible to the program - in this case, one of the indices of the input vec2.

Sign in to add a comment