Closed Bug 594357 Opened 9 years ago Closed 9 years ago

[WebGL][D3D9] crash on some WebGL demos with Intel OpenGL renderer [@ ig4icd32.dll@0x5b73b0 ] (8.15.10.2189) [@ ig4icd32.dll@0x5b7390 ] (8.15.10.2226)

Categories

(Core :: Canvas: WebGL, defect, critical)

x86_64
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: scoobidiver, Unassigned)

References

(Blocks 1 open bug)

Details

Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre

Steps to reproduce :
1. go to http://learningwebgl.com/lessons/lesson07/index.html
2. open a second tab and go to http://o3d.googlecode.com/svn/trunk/samples_webgl/o3d-webgl-samples/pool.html and wait the complete load
3. select the first tab. It causes the crash.

Signature	ig4icd32.dll@0x5b73b0
UUID	fa9cc67b-3999-4d03-b018-813be2100908
Time 	2010-09-08 06:06:17.352547
Uptime	26
Last Crash	30 seconds before submission
Install Age	1143 seconds (19.1 minutes) since version was first installed.
Product	Firefox
Version	4.0b6pre
Build ID	20100908040849
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x8
App Notes 	AdapterVendorID: 8086, AdapterDeviceID: 2a42

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	ig4icd32.dll 	ig4icd32.dll@0x5b73b0 	
1 		@0x447bbfff 

Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family
Vendor ID: 8086
Device ID: 2a42
Adapter RAM: Unknown
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Driver Version: 8.15.10.2189
Driver Date: 7-28-2010
Direct2D Enabled: false
DirectWrite Enabled: false
GPU Accelerated Windows : 1/1 Direct3D 9
No crash here on linux x86-64 / nvidia. Tried both with and without accelerated layers (OpenGL).

I can see that you are using accelerated layers (Direct3D 9). Does the bug persist if you disable them (preferences layers.accelerate_xxx and/or environment variable MOZ_ACCELERATED) ?

If the bug persists, this is almost certainly an Intel driver issue, we should report to them.

If the bug doesn't persist, this can be either a driver issue or a bug on our side.
Ah one more possibility is that we forgot to call MakeCurrent() in some WebGL function implementation. This could result in a subsequent draw-call crashing, I guess. I wonder how we could check if this is the case?
I set :
layers.accelerate-all to false
layers.accelerate-none to true
so that :
GPU Accelerated Windows : 0/1 Direct3D 9

It does not crash any more.
Ah, interesting. This pretty much rules out a missing MakeCurrent() as cause of the crash. Can still be either driver bug or our bug (possibly in Layer manager?).
Your stack trace is almost empty. Is it always like that?

0  	ig4icd32.dll  	ig4icd32.dll@0x5b73b0  	
1 		@0x447bbfff

I wonder what is @0x447bbfff. It can't be JIT'ted JS code calling WebGL functions, because if it were that, we would see WebGL functions in between. At the same time it doesn't seem to be an address from any module you have loaded in your process' address space:

Module|sysenv.dll|3.1.72.0|sysenv.pdb|1F0141D6F9E3443D876340D3934F16461|0x011f0000|0x01234fff|1 Module|firefox.exe|2.0.0.3903|firefox.pdb|B0505351EFAE43D5921C32A415A097112|0x012f0000|0x01307fff|0 Module|igdumdx32.dll|8.15.10.2189|igdumdx32.pdb|6594D80E98AE4DCE830BF75FF917ED211|0x06c00000|0x06c90fff|0 Module|igdumd32.dll|8.15.10.2189|igdumd32.pdb|80A443E4CFD34F71AB23F743260FC0491|0x08aa0000|0x08f70fff|0 Module|ig4icd32.dll|8.15.10.2189|ig4icd32.pdb|582DDD4A89C34032B64A192018BA65A81|0x0cb00000|0x0d5a4fff|0 Module|psdprotect.dll|3.1.72.0|PSDProtect.pdb|09875947261244AEA568B84589E74E9C1|0x10000000|0x1001cfff|0 Module|xul.dll|2.0.0.3903|xul.pdb|1869EA22A27A46D49A3A946F1F122C402|0x6e1f0000|0x6f023fff|0 Module|propsys.dll|7.0.7600.16385|propsys.pdb|84CE69230C0D40F19807CF3930FCE85E2|0x71930000|0x71a24fff|0 Module|opengl32.dll|6.1.7600.16385|opengl32.pdb|D6A5E50ACC5C4AF59FF7B7B387CA4A2A2|0x71a60000|0x71b27fff|0 Module|rasadhlp.dll|6.1.7600.16385|rasadhlp.pdb|9C177D0E6FD14D28BAE05D9757E8182F2|0x72870000|0x72875fff|0
Other webgl demos crash my graphic driver (unable to reproduce) with the same signature but a different crashing thread :
0  	ig4icd32.dll  	ig4icd32.dll@0x5b73b0  	
1 		@0x43f9fff

0  	ig4icd32.dll  	ig4icd32.dll@0x5b73b0  	
1 		@0x43efffff
.....

For more info, see :
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b6pre&query_search=signature&query_type=exact&query=ig4icd32.dll%400x5b73b0&date=09%2F08%2F2010%2008%3A33%3A31&range_value=1&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=ig4icd32.dll%400x5b73b0

The crash signatures are similar to the one in bug 582368 which was caused by the graphic driver.

Andrzej, what is your opinion ?
Here is a simpler testcase :
http://o3d.googlecode.com/svn/trunk/samples_webgl/o3d-webgl-samples/multiple-clients.html
It crashes consistently Minefield 32-bit with D3D9 ON and WebGL enabled on x86_64 platform. It does not crash Minefield 64-bit with these 2 conditions.

Signature	ig4icd32.dll@0x5b71b0
UUID	c2a84c98-7330-44ec-889a-db9372100909
....
0  	ig4icd32.dll  	ig4icd32.dll@0x5b71b0  	
1 	ntdll.dll 	ntdll.dll@0x3bb35 	

With D3D9 ON (layers.accelerate-all to true) and webgl enabled (webgl.enabled_for_all_sites to true) (necessary conditions), this URL does not crash b6pre/20100904, it crashes b6pre/20100905. So the regression range is :
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bd474ff6f86c&tochange=fd13b6ce36bd

It can be Core Canvas WebGL bug, or Core Graphics bug, or even graphic driver bug.
Summary: Intel graphic driver crash with 2 loaded webgl demos [@ ig4icd32.dll@0x5b73b0 ] → [WebGL][D3D9] Intel graphic driver crash with some webgl demos [@ ig4icd32.dll@0x5b73b0 ]
Could you please try adding gl.finish() calls after every WebGL call in your testcase. Indeed, in another recent bug (bug 593867) that allowed us to go from a useless stack trace (such as the one you're getting here) to a useful one. (Of course don't do this in production code, it'll be very slow).

I think I'll add a "OpenGL debug mode" where we do glFinish() automatically after every OpenGL call. Until we have that, you need to add gl.finish() manually in your javascript in order to get a hopefully meaningful stack trace.
Following the comment 8 requirements :
I added o3djs.webgl.finish(); at the end of setup(), createCube(), onrender() functions.
In the WebConsole, the following error is displayed :
"Exception : null has no properties Fichier source : file:///C:/Users/Pierrot/Downloads/multiple-clients-modified.html Ligne : 0, Colonne: 88 Catégorie : content javascript"

I loaded the google home page soon after and then I went back to my testcase.
I had a crash at a different signature :
Signature	ig4icd32.dll@0x1a7155
UUID	52ce377c-6bfd-4d17-8bef-5d1082100910
This still looks like it could use more finish() calls. I know practically nothing about javascript but don't you have a way to do something like:

  for (all methods in gl object) {
     override that method by one that calls it and then calls finish();
  }

again... I'm working on adding an option to firefox that will do that directly at the level of the OpenGL library.
> I know practically nothing about javascript
Me too !
Try to find someone else in Mozilla, he can attach a testcase based on the google webgl sample, and I can test it on my computer.
Depends on: 597881
Blocks: 605779
let's call this a dup of the ANGLE bug
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 603367
It is not fixed.
See crash report: dfcf8310-841a-4983-8679-5bc1b2101214
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: [WebGL][D3D9] Intel graphic driver crash with some webgl demos [@ ig4icd32.dll@0x5b73b0 ] → [WebGL][D3D9] Intel graphic driver crash with some webgl demos [@ ig4icd32.dll@0x5b73b0 ] (8.15.10.2189) [@ ig4icd32.dll@0x5b7390 ] (8.15.10.2226)
Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family
Vendor ID: 8086
Device ID: 2a42
Adapter RAM: Unknown
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Driver Version: 8.15.10.2226
Driver Date: 10-15-2010
Direct2D Enabled: true
DirectWrite Enabled: true
WebGL Renderer: Intel -- Mobile Intel(R) 4 Series Express Chipset Family -- 2.1.0 - Build 8.15.10.2226
GPU Accelerated Windows: 1/1 Direct3D 10
I just got this crash while visiting http://bodybrowser.googlelabs.com/. First my display driver crashed and then it took down the browser.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre

http://crash-stats.mozilla.com/report/index/bp-409df259-2e62-49d0-af99-3671c2110106
I installed DirectX runtime, so that:
WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 10
2011 19:54:16)
Fx4.0b9 no longer crashes with STR in comment 0 or comment 7.
Summary: [WebGL][D3D9] Intel graphic driver crash with some webgl demos [@ ig4icd32.dll@0x5b73b0 ] (8.15.10.2189) [@ ig4icd32.dll@0x5b7390 ] (8.15.10.2226) → [WebGL][D3D9] crash on some WebGL demos with Intel OpenGL renderer [@ ig4icd32.dll@0x5b73b0 ] (8.15.10.2189) [@ ig4icd32.dll@0x5b7390 ] (8.15.10.2226)
(In reply to comment #15)
> I just got this crash while visiting http://bodybrowser.googlelabs.com/. First
> my display driver crashed and then it took down the browser.
> 
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110106
> Firefox/4.0b9pre
> 
> http://crash-stats.mozilla.com/report/index/bp-409df259-2e62-49d0-af99-3671c2110106


still reproducable?
Blocks: 623319
if it is probably should nominate for blocking 2.0.  bodybrowser crashes rank high in firefox 4 crash data site lists, and on input.  see Bug 623319
All due to intel's OpenGL drivers.  These will be blocked when the patch for bug 625118 goes in.
> These will be blocked when the patch for bug 625118 goes in.
I though to there were two conditions to not use the OpenGL driver:
1. use ANGLE
2. have the DirectX runtime installed
bug 625118 will solved the first condition for Intel's GPUs, not the second one.
May be I am wrong about the second condition.
With today's build, there is no need to install DirectX runtime to use ANGLE:
WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Depends on: 625118, 629538
Resolution: --- → WORKSFORME
Wait.. how's that possible? As far as I know, we still don't ship the DirectX runtime bits, do we?

What today's build, the news is that ANGLE works again (provided that you have DirectX runtime installed). It hadn't been working in the past 2 days.
Another relevant bit of news is that we now blacklist OpenGL on intel cards on Windows. So if you can't use ANGLE, then you can't get WebGL at all.
Shipping the needed DirectX runtime file will be done by bug 630628.

But since we are already blacklisting OpenGL on Intel cards on Windows, the crash is already fixed, yeah.
You need to log in before you can comment on or make changes to this bug.