[Bug 71254] Mesa crash on shaders that have large number of active uniforms.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71254

--- Comment #4 from Kevin Rogovin <kevin.rogovin at intel.com> ---
I do not think changing the array size from MAX_UNIFORMS to 4*MAX_UNIFORMS will
fix either crash causes.

The first crash cause, writing past the array. The first main issue is this:
the real beans is not so much maximum number of uniforms, but maximum number of
-active- uniforms. If that is true, then unless the GLSL front-end walks the IR
and removes dead code to then compute the "active" uniforms, then the issue
shall remain. If GLSL IR does do that or is modified to do so, or in a pinch
modified to simply reject immediately GLSL code that goes past the MAX_UNIFORMS
limit then leaving that array as MAX_UNIFORMS in size is fine.

However, the correct solution is to just make the array dynamic in size; the
obvious benefit is that it will likely even save a little memory since only
room needed to enumerate the uniforms for an active shader will be allocated.


The second cause, the stack overflow on visitors. One can machine generate
expressions that only use -one- uniform (or just an in, be it shader global
scope of function scope) that cause the stack overflow. Fixing this is
non-trivial except to just not bother walking such large expressions.

One can argue that "real application" code would not have such expressions.
That argument does not pan out so well when inlining comes into play. Imagine a
noise computation where the the arguments fed to it are also noise values and
so on. Even ignoring that case, a GL implementation must also guard against
malicious shaders (in particular well formed malicious shaders). The severe
burning example is using Mesa on a system that has a browser that implement
WebGL. At the end of the day, all those shaders from the *web* will be passed
to the GL implementation. Crash driver, will potentially crash the browser. For
the case of Chrome/Blink, this will crash the GPU process of a browser which
will likely bring down all GL state for all WebGL canvases and likely just
crash the entire browser too.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20131106/2da16d9a/attachment.html>