I think these issues might be related: https://bugs.chromium.org/p/chromium/issues/detail?id=778188&q=webgl&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

Can also add that I have no issues in Chrome Canary ( 64.0.3250.0 )

 Issue 778188  has been merged into this issue.

I'll do a bisect. Unclear what CL fixed this.

adam.larkeryd@gmail.com, thanks for the simple reproduction case.

Ran python bisect-builds.py --use-local-cache -b 499098 -g 511680 -a win64 -- https://jsfiddle.net/wy3cra8g/. Bisect produced this "fixed" regression range:

You are probably looking for a change made after 502908 (known bad), but no later than 502925 (first known good).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/5c27449fed6260ae4d21160b589d07785964bbd4..b9b7f3af9dedb31ffa7938ed8c508c6c9ff5e754

This has an ANGLE roll:

https://chromium.googlesource.com/angle/angle.git/+log/371ed53..abd3135

I'm pressure sure the fix is "D3D11: Re-check disabled attribs on VAO switch." by yours truly.

https://chromium-review.googlesource.com/669963

This means the fix is in for M63 and it's unlikely there's action we can take except wait for a few more weeks. Ken/Kai if you disagree please follow up.

pretty sure**

I will say, however, that this is a pretty clean cherry-pick. I'll merge-request and see what folks have to see.

Marking merge request - this fixes quite a nasty crash in shipping WebGL applications. The fix applies cleanly to top-of-tree M62/3202 and requires no conflict resolution. It has been working in M63 and M64 for more than a month, so should be considered extremely safe. Please review.

Fix here: https://chromium-review.googlesource.com/669963

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+ Abdul

Thanks - we are shipping out M62 today. What is the full impact of this bug and what are the drawbacks if we consider this for M63?

Thanks as well.

This crash could theoretically affect any client calling the GPU process. Most frequently it will be WebGL users whose shipping applications suddenly trigger unexpected crashes. The consequences could be that for six weeks, the GPU process suffers random instability and/or a number of broken WebGL applications.

Please note that it still crashes on sketchfab, on chrome 62 on the inspector UV checker on that model 
https://sketchfab.com/models/0782d9f75d794e86b14614e58a3095f0?webgl_timer_gpu=0 on chrome 62 windows 10.
( but not on canary chrome 64. )

Attached is a spectorjs trace of all gl commands issued on a frame when drawing the mesh with uv, viewable by unzip and drag&drop on the popup of the extension, if it's of any interest.

Deleted: capture 07_07_51.7z 419 KB

capture 07_07_51.7z 419 KB Download

Thanks for the quick responses!
I will have to refrain from using VAOs until this issue is fixed because of unreliable crashes in our WebGL application. Glad the issue was replicatable and found.

Another bug VAO: 

https://sketchfab.com/models/8373e3937bf8429c9491809752758454

(whereas https://sketchfab.com/models/8373e3937bf8429c9491809752758454?use_vao=0 works)

Confirmed that https://sketchfab.com/models/8373e3937bf8429c9491809752758454 is working fine in 63.0.3239.18 (Official Build) beta (64-bit) (cohort: Beta) .

abdulsyed@: I would like to urge that we cherry-pick jmadill@'s fix to M62. Somehow this bug slipped through the cracks during testing.

 Issue 778186  has been merged into this issue.

 Issue 779434  has been merged into this issue.

Thanks for the fix - can you please comment on how safe this merge is overall? Since M62 is already ramp-ing up, we need to ensure to take absolutely critical fixes that have 0 chances of introducing new regressions. Seems like fix has been out for a while, but please confirm if this well tested in canary/dev/beta.

(apologies if you've already answered these in comments above).

The fix went in approximately two weeks after the regression, so it has been in Canary/Dev/Beta for quite a long time (two months). It's a one line change and is very conservative:

https://chromium-review.googlesource.com/c/angle/angle/+/669963/3/src/libANGLE/renderer/d3d/d3d11/StateManager11.cpp

It applies without merge conflicts to our M62 branch of ANGLE. I believe it is totally safe and would not have a chance of introducing new regressions.

Thanks!

ok great, approving this merge for M62. Branch:3202. 
We don't have a respin planned yet. 

Awesome, thanks. Will merge to our branch for M62.

The following revision refers to this bug:
  https://chromium.googlesource.com/angle/angle/+/842c43ae67bad842fa0364e625fdee34e8857aa8

commit 842c43ae67bad842fa0364e625fdee34e8857aa8
Author: Jamie Madill <jmadill@chromium.org>
Date: Wed Nov 01 03:20:01 2017

D3D11: Re-check disabled attribs on VAO switch.

When switching VAOs, if we switch to a VAO which has disabled
attributes, we could occasionally in some edge cases not have a buffer
initialized to render with. Fix this by re-checking the current
value (disabled) attributes every VAO switch.

Probably a regression caused by d28758d:
"D3D11: Re-enable updateVertexBuffer dirty bits."

BUG= chromium:778689 

Change-Id: I01814bafa1d6e3a7d6a5c03bc5d058f39346f087
Reviewed-on: https://chromium-review.googlesource.com/748426
Reviewed-by: Jamie Madill <jmadill@chromium.org>

[modify] https://crrev.com/842c43ae67bad842fa0364e625fdee34e8857aa8/src/libANGLE/renderer/d3d/d3d11/StateManager11.cpp
[modify] https://crrev.com/842c43ae67bad842fa0364e625fdee34e8857aa8/src/tests/gl_tests/StateChangeTest.cpp

We would very much like to to know when the fix will be in Stable ?

( sketchfab.com webgl crashes repeatedly )

paul, I think they're doing a rollout of a new version of stable very soon. Not sure on an exact timeline, maybe a few days. Thanks for your patience.

Thanks for the quick answer!

No problem. Actually I may have spoke too soon though, it looks like this fix didn't make it into the latest rollout (62.0.3202.75) so it will be in the one after that, which isn't scheduled yet. Hopefully a week or two at most.