634817 - WebGL GLSL, too many instructions causes FireFox to crash [@ d3dcompiler_42.dll@0xf21a8]

Status: RESOLVED DUPLICATE of bug 648804

(Core :: Graphics: CanvasWebGL, defect)

Description

[warcraftthreeft]

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

Make a shader, like a fragment shader, with a ton of instructions (meaning a lot of operations). Firefox will crash instantly.

Reproducible: Always

Steps to Reproduce:
1. Make a shader, like a fragment shader, with a ton of instructions (meaning a lot of operations).
2. Watch Firefox will crash instantly.
Actual Results:  
Firefox crashes

Expected Results:  
Warning about instruction limit or something?

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Can you create and attach a reduced Testcase showing the Issue?
https://bugzilla.mozilla.org/attachment.cgi?bugid=634817&action=enter

Moreover, please post the Content of the Graphics Section you can get via "about:support".

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

It would also be interesting to know if other browsers crash too, and if in about:config you have webgl.shader_validator=true.

Comment 3

[warcraftthreeft]

http://assaultwars.com/javascriptgame/webgl/webglvoxels.html

I submitted the bug to chrome and they "fixed" it already, so I'm not sure any other browser are affected.

Yes webgl.shader_validator=true is set to true.

Adapter Description NVIDIA GeForce Go 7800
Vendor ID10deDevice ID0098
Adapter RAM 256
Adapter Drivers nvd3dum nvwgf2um
Driver Version 7.15.11.7948
Driver Date 1-30-2009
Direct2D EnabledBlocked on your graphics driver. Try updating your graphics driver to version 257.21 or newer.
DirectWrite Enabledfalse (6.1.7600.20830, font cache n/a)
WebGL Renderer Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)
GPU Accelerated Windows 0/1

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Firefox doesn't crash instantly, it locks up for a while -- and eventually crashes with https://crash-stats.mozilla.com/report/index/bp-780f8280-c7fc-408a-8575-532892110221.

Not sure what the chrome fix for this is likely to be...

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(putting this down as a softblocker)

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

While firefox is locked up, it's all inside the d3d shader compiler.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

In Chrome, this seems to be handled by the separate GPU process/thread -- it gets killed off because it's being unresponsive.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: testcase

attaching the testcase for reference.  Note that it includes an infinite loop in a shader, just doesn't happen to be written as a simple while(true).

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: testcase with Go button

Comment 11

[Nochum Sossonko [:Natch]]

Mozilla/5.0 (Windows NT 6.0; rv:2.0b12pre) Gecko/20110221 Firefox/4.0b12pre

Works fine for me (and pretty speedy too).

Comment 12

[José Jeria]

(In reply to comment #11)
> Mozilla/5.0 (Windows NT 6.0; rv:2.0b12pre) Gecko/20110221 Firefox/4.0b12pre
> 
> Works fine for me (and pretty speedy too).

Build ID: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre

Still seeing what comment 4 describes.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage

Comment 14

[Arthur K. (he/him)]

is there a reason that D3DCompiler_42.dll (build 9.27.952.3022) and d3dx9_42.dll (build 9.27.952.3022) are included with Fx4 and not build 9.29.952.3111 of both
DLLs? Has anyone tried with the newer build?

Try this experiment: grab the more current DLLs from the June 2010 ReDist,
rename the current ones in the Firefox DIR and import the updated ones and rename the file version from 43 to 42 and see what happens.

Comment 15

[Masatoshi Kimura [:emk]]

Fx4 (with default 42 DLLs): crash.
Local build with 43 DLLs: locking up for a while, but didn't crash.
Updating DXSDK may help.

Comment 16

[Arthur K. (he/him)]

That did somewhat confirm my suspicions. However, I don't know---statistically speaking---how many XP/Vista/Win 7 users actually go out and grab the redist or web updater package and update their DirectX to the most current version available. It's not like MS makes it easy via some mechanism like Win Update. But, I'm glad that my suggestion was independently tested.

Failing having users update their DX DLLs via the redist or web update, perhaps updating the version included with the installer to current may help some. As it stands, the quarterly updates I used to see have stopped since the redist from June 2010 was released. This may lead one to conclude that nothing new for Win XP will come down the pipe and unless you're on Vista / Win 7's DX, you're SOL.

Comment 17

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #14)
> is there a reason that D3DCompiler_42.dll (build 9.27.952.3022) and
> d3dx9_42.dll (build 9.27.952.3022) are included with Fx4 and not build
> 9.29.952.3111 of both
> DLLs? Has anyone tried with the newer build?

The only reason is that the build slaves still have the old DirectX SDK installed. Need to file a rel-eng bug to get that updated.

(In reply to comment #15)
> Fx4 (with default 42 DLLs): crash.
> Local build with 43 DLLs: locking up for a while, but didn't crash.
> Updating DXSDK may help.

Interesting. One more reason to update to 43. (Another reason is that latest ANGLE doesn't support 42 anymore so we have to patch it).

Comment 18

[Arthur K. (he/him)]

Too bad 43 isn't making it into 4.0.1.

Comment 19

[MrX1980]

http://madebyevan.com/webgl-path-tracing/ -> crash (always)

https://crash-stats.mozilla.com/report/index/2147c63f-4264-4ffc-91cf-ed2332110423

Comment 20

[MrX1980]

It seams to work now with:
Aurora: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0a2) Gecko/20110521 Firefox/5.0a2

Nightly: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110521 Firefox/6.0a1

I see now the D3DCompiler_43.dll and d3dx9_43.dll files.

Comment 21

[Arthur K. (he/him)]

Great! That should help out a lot of people.

Comment 22

[Daniel Veditz [:dveditz]]

Does comment 20 mean the bug 648804 got fixed? It's still open.

Comment 23

[Benoit Jacob [:bjacob] (mostly away)]

Yes, I'm pretty sure that's what it means. CC'ing Chris Atlee who will be happy to see that users are noticing. Closing as duplicate.