Open Bug 1124427 Opened 5 years ago Updated 2 years ago

Microsoft WebGL Stress Test crashes Firefox

Categories

(Core :: Graphics, defect, P3, critical)

36 Branch
defect

Tracking

()

People

(Reporter: smichaud, Unassigned)

References

()

Details

(Keywords: crash, Whiteboard: [gfx-noted])

Crash Data

I've seen crashes on OS X 10.8.5 in FF 35, but I expect I've only scratched the surface.

I haven't yet seen any crashes on Windows.  But that's probably because I can only run Windows in a virtual machine (using VMWare).  In a VMWare virtual machine (Windows or OS X), you get an error that WebGL can't be initialized.

This stress test was mentioned in an unrelated bug, at bug 1028424 comment #28.
On Windows 7 - Intel HD3000
https://crash-stats.mozilla.com/report/index/67afbdd1-d183-49c0-91c8-508672150122
Notebook went black, recovered and told me that the driver had crashed but recovered sucsessfully.
OS: Mac OS X → All
Adding signatures from comment #1 and bug 1028424 comment #31 - i.e. bp-906e3b50-ac4a-4366-88c5-1fcde2150122
Crash Signature: [@ libsystem_kernel.dylib@0x16282 ] [@ rx::priv::GenerateMip_XY<rx::B8G8R8A8> ]
Keywords: crash
Just to be clear - in this bug, we are not attempting to save the driver from resetting (the author can usually always force that), we just want to make sure Firefox doesn't crash when driver resets.
Do we have crash reports for this from Windows?
Whiteboard: [gfx-noted]
Adding another crash signature for this site, for Firefox 36 on Windows 8.1: https://crash-stats.mozilla.com/report/index/eb7352cc-2e16-4415-a19b-eacf22150211
Crash Signature: [@ libsystem_kernel.dylib@0x16282 ] [@ rx::priv::GenerateMip_XY<rx::B8G8R8A8> ] → [@ libsystem_kernel.dylib@0x16282 ] [@ rx::priv::GenerateMip_XY<rx::B8G8R8A8> ] [@ @0x0 | mozilla::gl::GLContext::fDeleteFramebuffers(int, unsigned int const*) ]
In Windows 7 on Nightly 38, the content process crashed first, then the browser process. 

Browser crash: 
https://crash-stats.mozilla.com/report/index/afbfbedb-65db-4ba8-8ced-62e662150211

The content crash signature was rx::priv::GenerateMip_XY<rx::B8G8R8A8>:  https://crash-stats.mozilla.com/report/index/66cbab38-c3dd-452b-b0fd-bcc162150211
Crashed in 37 with [@ @0x0 | mozilla::gl::GLContext::fDeleteFramebuffers(int, unsigned int const*) ]. 
Report: https://crash-stats.mozilla.com/report/index/65d00522-04a1-4f51-91a3-df7192150211
Investigating on OSX, after pushing the button a couple of time, I see:

0 __pthread_kill
7 intelSubmitCommands
8 mozilla::gl::GLContext::fFlush()
9 mozilla::gl::GLContext::FlushIfHeavyGLCallsSinceLastFlush()

A little more digging uncovers that the driver is calling abort(). If the driver is going to kill the current thread, we could try catching SIGABRT but that's not something I'm comfortable commenting on.
(In reply to comment #9)

If the driver wants to kill the current process, I think it's probably best to just let it do that.

I opened this bug in the hope that there might be something we can do about these crashes.  Maybe there isn't.
Ideally on Windows we can recover from a TDR; on other platforms, the best we can do is make sure that the shutdown is purposeful (e.g. driver calling abort() and not crash due to random memory corruption).
FF 41b5, WinXP - https://crash-stats.mozilla.com/report/index/1c50bc81-ff84-400f-bceb-60aff2150828

FF crashes very often using the following STR:
1. Open http://madebyevan.com/webgl-water/ in a new tab
2. Lock computer (Windows key + L)
3. Unlock computer

Actual result: FF crash
This last workflow seems to be OK on Windows 7, with D3D9 and D3D11; do we have any non-XP Windows crashes?
(In reply to Milan Sreckovic [:milan] from comment #13)
> This last workflow seems to be OK on Windows 7, with D3D9 and D3D11; do we
> have any non-XP Windows crashes?

Looking at the latest stats, most of the crashes are on Windows 7:

Windows 7 	64.18 %	301
Windows Unknown 	19.83 %	93
Windows 8.1 	8.96 %	42
Windows XP 	4.26 %	20
Windows 8 	1.92 %	9
Windows Vista 	0.85 %	4 

Source: https://crash-stats.mozilla.com/report/list?signature=%400x0%20|%20mozilla%3A%3Agl%3A%3AGLContext%3A%3AfDeleteFramebuffers%28int%2C%20unsigned%20int%20const*%29
Bunch of these (but not all, so probably not relevant) are WGL+.  Some of them are WebGL+, followed by WebGL-, perhaps we can't go to WebGL after the reset?
The tests seem to have moved?
(In reply to Milan Sreckovic [:milan] from comment #16)
> The tests seem to have moved?

Seems to be. Here are some demos tagged "WebGL":
https://dev.modern.ie/testdrive/tags/webgl/
Crash Signature: [@ libsystem_kernel.dylib@0x16282 ] [@ rx::priv::GenerateMip_XY<rx::B8G8R8A8> ] [@ @0x0 | mozilla::gl::GLContext::fDeleteFramebuffers(int, unsigned int const*) ] → [@ libsystem_kernel.dylib@0x16282 ] [@ rx::priv::GenerateMip_XY<rx::B8G8R8A8> ] [@ @0x0 | mozilla::gl::GLContext::fDeleteFramebuffers(int, unsigned int const*) ] [@ rx::priv::GenerateMip_XY<T> ] [@ @0x0 | mozilla::gl::GLContext::fDeleteFramebuffers ]
We had 118 reports during the Firefox 48.0.1 cycle but none so far with Firefox 49.0.1. Will leave this open for another cycle to see if more reports come in.
Version: unspecified → 36 Branch
You need to log in before you can comment on or make changes to this bug.