Closed Bug 639811 Opened 12 years ago Closed 11 years ago

[ANGLE] Very simple shader crashes Minefield [@ TParseContext::constructorErrorCheck(int, TIntermNode*, TFunction&, TOperator, TType*) ]

Categories

(Core :: Graphics: CanvasWebGL, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- .x+

People

(Reporter: secretrobotron, Assigned: bjacob)

References

()

Details

(Keywords: crash, testcase, Whiteboard: [sg:dos null-deref])

Crash Data

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre

Browser crashes when creating this shader:

Vertex Shader:
'void main(void) { mat3(); gl_Position = vec4(1.0); }';

Fragment Shader:
'void main(void) { gl_FragColor = vec4(1.0); }';

From testing, the focal point seems to be that 'mat3()' in the vertex shader. Also occurs with mat4(), vec3(), etc., as long as no args are supplied.

Also happens in Chrome 9.0.597.107.


Reproducible: Always

Steps to Reproduce:
1. Go to http://dl.dropbox.com/u/7054348/shader_crash_test.html
2. Watch browser crash.



https://crash-stats.mozilla.com/report/index/fe3eef61-aa2d-4cb8-9447-154662110308
Summary: Very simple shader crashes Minefield → [ANGLE] Very simple shader crashes Minefield [@ TParseContext::constructorErrorCheck(int, TIntermNode*, TFunction&, TOperator, TType*) ]
I can confirm here on OSX 10.6.6 as well:


Minefield 4.0b13pre (2011-03-03) - Crashed

WebKit 5.0.3 (6533.19.4, r80210) - Crashed

Chrome 9.0.597.107 - Works, no crash


GPU: 
 Chipset Model:	NVIDIA GeForce GT 330M
  Type:	GPU
  Bus:	PCIe
  PCIe Lane Width:	x16
  VRAM (Total):	512 MB
  Vendor:	NVIDIA (0x10de)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Trivial null-pointer deref, making patch, not yet fixed upstream.
Attached file minimal testcase
Attached patch check for nullSplinter Review
This fixes the crash and does not cause a regression in the test suite.
Attachment #517736 - Flags: review?(joe)
Requesting .x+ blocker
blocking2.0: --- → ?
blocking2.0: ? → .x+
Duplicate of this bug: 639918
OS: Windows 7 → All
when do we think this might have regressed, or is it a long standing bug?

I don't see any crashes until mar7 showing up on trunk builds from mar3
         TParseContext::constructorErrorCheck.int,.TIntermNode...TFunction.,.TOperator,.TType..
date     total    breakdown by build
         crashes  count build, count build, ...

20110301   
20110302   
20110303   
20110304   
20110305   
20110306   
20110307 6  	3 4.0b13pre2011030312, 
        		3 4.0b13pre2011030303,
(In reply to comment #9)
> when do we think this might have regressed, or is it a long standing bug?

This is a long-standing bug.

> 
> I don't see any crashes until mar7 showing up on trunk builds from mar3

Probably because you have to use a rather unusual construct in a shader in order to trigger the bug.
Comment on attachment 517736 [details] [diff] [review]
check for null

Patch has been checked in upstream. So this bug will be fixed the next time that we sync our ANGLE copy.
Attachment #517736 - Flags: review?(joe)
Keywords: crash, testcase
Whiteboard: [sg:dos null-deref]
We're now using ANGLE r653, so this should be fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee: nobody → bjacob
Crash Signature: [@ TParseContext::constructorErrorCheck(int, TIntermNode*, TFunction&, TOperator, TType*) ]
You need to log in before you can comment on or make changes to this bug.