Note that this is a regression from Chrome 53, which works fine.

This seems to affect a lot of Unity content. Possibly related: https://bugs.chromium.org/p/chromium/issues/detail?id=646772

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

Looking.

Possibly not ANGLE.

Downloaded 414607 [1], issue reproduced.
Checkout out ANGLE ca05a0816096 (version present in [1]), ran in latest Canary, did not reproduce.
See link [2] for list of places this error string can come from. Possibly Skia related? Could be wrong here, just a thought.
Send this back to me if you want me to bisect start/end regression ranges, but it's possible it's not ANGLE.

[1]: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/414607/
[2]: https://cs.chromium.org/search/?q=%22flex+scanner+internal+error%22&sq=package:chromium&type=cs

Thanks Jamie for your help -- could you please help push this a little further? Given that Unity's shaders aren't loading I strongly suspect it's WebGL's shader translator that's causing the problem.

Ah, good point Ken, it's probably a crash in the shader translator baked into Chrome. I'm happy to take this back.

Going to steal this to bisect.

Bisect results for bad -> good for 'win':

https://chromium.googlesource.com/chromium/src/+log/252dbee7b15f43aa53242b68eb1bc41b272eaf26..19cd3064a23e7e953cafe855086c0aa9ce54dc7a

No idea why it won't bisect any narrower. Can't use 'win64' because of  issue 478255 . Will manually bisect the last bit. I didn't see a single ANGLE roll in the range above.

Narrow bisect shows the fix happened between 414882 and 414924.

https://chromium.googlesource.com/chromium/src/+log/f05e88ae004f438fcd8fb2023b51ba19a7903e48..69be1c3956d4dbff1062172e3a9ec19191dbc52f

There might be some value in doing a full bisect of this regression range. I'm not sure if I'll be able to complete that tonight, so sending back to Kai.

Can the Linux archive provide any narrower bisect?

https://chromium.googlesource.com/chromium/src/+/d4a17e1863ab232b718caeb4afdd4252af99cef0 looks suspicious -- a change in string handling in the JavaScript bindings.

Both this and  https://crbug.com/646772  seem to be due to a roll of V8:
https://chromium.googlesource.com/chromium/src/+/9ebe11cce19412b8f25312dbf31f747858e3b5b2

EDIT: Not due to, but fixed in* that roll of V8.

Thanks Kai for tracking that down.

V8 folks: there are an awful lot of revisions in that roll. Is there any chance you all could help pinpoint which one caused this regression?

Clarification: that V8 roll _fixes_ the problem that is appearing in beta (but does not exist in canary). I guess we would need to cherry-pick it into beta(?)

You're right -- I meant to say, pinpoint the one which fixed the regression.

Kai, do you think you could also bisect further back in the Chromium continuous build archive to find the V8 roll which introduced the regression in the first place?

There's no way to cherry-pick the entire roll into beta, but if we can figure out exactly what caused it, the V8 team can see if it's plausible to cherry-pick that revision into the beta branch.

Okay, I'm on it.

Here's the roll that caused the regression:
https://chromium.googlesource.com/chromium/src/+/59633d9ab185f5fe4900efe25286a16ee5fbbca9

Thanks Kai.

It looks an awful lot to me like a bug in https://chromium.googlesource.com/v8/v8/+/c7a2046670468b900b9dbbb4ce45beb5e0e717fd . V8 team, do you agree?

The roll is so big because this is the first roll after branch cut which contains around one day of work.

kbr@ why do you think this is because of https://chromium.googlesource.com/v8/v8/+/c7a2046670468b900b9dbbb4ce45beb5e0e717fd? I think the culprit is more in TurboFan related code.

bmeurer@, please check. The bug was introduced in https://chromium.googlesource.com/v8/v8/+log/adf28cfa..edd9dc88 and fixed in https://chromium.googlesource.com/v8/v8/+log/5ce28276..b93459dd.

hablich@: you are probably right -- I incorrectly assumed Turbofan was mainly being used for WebAssembly.

The real fix is in https://codereview.chromium.org/2276273002.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/c71964e9c77df872fe131be0937abae86d2b10b9

commit c71964e9c77df872fe131be0937abae86d2b10b9
Author: Benedikt Meurer <bmeurer@google.com>
Date: Fri Sep 16 06:51:20 2016

Merged: [turbofan] Disable LoadElimination completely for asm.js.

Revision: b471d4ab5cf48c754d4a3c616e932828a48ab4f8

BUG= v8:5308 , chromium:646737 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=ishell@chromium.org

Review URL: https://codereview.chromium.org/2342223003 .

Cr-Commit-Position: refs/branch-heads/5.4@{#51}
Cr-Branched-From: 5ce282769772d94937eb2cb88eb419a6890c8b2d-refs/heads/5.4.500@{#2}
Cr-Branched-From: ad07b49d7b47b40a2d6f74d04d1b76ceae2a0253-refs/heads/master@{#38841}

[modify] https://crrev.com/c71964e9c77df872fe131be0937abae86d2b10b9/src/compiler/pipeline.cc
[add] https://crrev.com/c71964e9c77df872fe131be0937abae86d2b10b9/test/mjsunit/asm/load-elimination.js

Is there anything pending in M54? If not please remove Merge-Approved-54 label.

Thanks a lot for the quick turnaround on this!

 Issue 646772  has been merged into this issue.