1124427 - Microsoft WebGL Stress Test crashes Firefox

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 1

[Guilherme Lima]

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.

Comment 2

[Robert Kaiser]

Adding signatures from comment #1 and bug 1028424 comment #31 - i.e. bp-906e3b50-ac4a-4366-88c5-1fcde2150122

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 4

[Bas Schouten (:bas.schouten)]

Do we have crash reports for this from Windows?

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Comment 1 - https://crash-stats.mozilla.com/report/index/67afbdd1-d183-49c0-91c8-508672150122

Comment 6

[Liz Henry (:lizzard)]

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

Comment 7

[Liz Henry (:lizzard)]

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

Comment 8

[Liz Henry (:lizzard)]

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

Comment 9

[u480271]

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.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

(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.

Comment 11

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

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).

Comment 12

[Paul Silaghi, QA [:pauly]]

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

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

This last workflow seems to be OK on Windows 7, with D3D9 and D3D11; do we have any non-XP Windows crashes?

Comment 14

[u279076]

(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

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

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?

Comment 16

[Milan Sreckovic [:milan] (needinfo for best results)]

The tests seem to have moved?

Comment 17

[u279076]

(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/

Comment 18

[u279076]

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.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.

Comment 21

[Steven Michaud [:smichaud] (Retired)]

The WebGL Stress Test still exists, but has moved to a new site:

https://testdrive-archive.azurewebsites.net/graphics/webglstresstest/

It no longer crashes Firefox (testing on macOS 12.6.3 with the current FF version, which is 109.0.1).