Closed Bug 594357 Opened 14 years ago Closed 14 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 :: Graphics: CanvasWebGL, defect)

Product:
Core
Component:
Graphics: CanvasWebGL
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: scoobidiver, Unassigned)

References

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: 14 years ago
Resolution: --- → DUPLICATE
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: 14 years ago → 14 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.