I reproduced this failure with 54.0.2840.16 on 10.12 beta, but I did not reproduce it with 55.0.2853.0.

Over to Blink>WebGL for further triage.

ANGLE folks: could one of you please help triage this? It sounds like a change in the shader translator.

Almost certainly the same as
https://bugs.chromium.org/p/chromium/issues/detail?id=646737

I agree. Let's duplicate this into the other bug once that's confirmed.

They both start failing and start passing again on the same V8 rolls. Is that enough to confirm it's a duplicate?

Let's leave this one open until we've confirmed that the fix (i.e., cherry-pick or revert on the V8 tree) fixes both. This is a really serious regression. Separately, it would be ideal if we could construct a regression test for this and add it to the WebGL conformance suite. If you can manage to track down the shader sources for one of the failing shader compilations, maybe we can figure out the pattern that causes it to fail.

I'm looking at this once since I was able to more easily pull it onto my local disk and beautify the asm.js source.

I don't see anything suspicious happening in shader compilation/program linking - the compile and link statuses seem fine - but I also don't know what Unity-internal logic prints "WARNING: Shader Unsupported: '...' - Setting to default shader." So I don't know how I can figure out what Unity thinks is wrong.

Hmm. Did you instrument the calls to glGetShaderiv for GL_COMPILE_STATUS and/or glGetProgramiv for GL_LINK_STATUS, on the service side, when either returns false? I have to assume that Unity's checking the return codes from those. Or maybe they're checking GL_VALIDATE_STATUS or something else? A ProgramInfoLog that's non-null? That was a problem at one point, where Chrome was returning a string that contained only a bogus null terminator.

Jonas, can you help us understand exactly how Unity's checking for these shaders being unsupported?

I only looked at the JS side. I put breakpoints on the asm.js implementations for CompileShader and LinkProgram and checked the compile and link status from the console (although I could have easily enough done the same thing by editing the asm.js code). I checked these statuses for all 2 programs that link before the first error is printed and they all returned true. I did not try breakpointing at the ProgramInfoLog implementation yet.

I actually don't think that this problem is related to shader handling in WebGL. Looking at https://bugs.chromium.org/p/chromium/issues/detail?id=646737#c13 (which I assume to be identical given the bisect), that one actually seems to fail in *our* shader parsing code, before anything gets passed to WebGL. In that case, the parser seems to hit a buffer overflow, in this one it just seems to fail. In either case, it seems that a change in V8 caused the flow of our code to break, and that seems to be the real problem here.

Jonas, I agree. The V8 team has taken over in
https://bugs.chromium.org/p/chromium/issues/detail?id=646737
I'll let them handle this going forward.

In that case the thing to do is duplicate this into the other bug. I'll take care of that.