Looks very similar to https://bugs.chromium.org/p/chromium/issues/detail?id=527930

To reproduce I had to serve the files using a local http server.
The bug is also present in the latest Chrome canary 58.

Bisect: 429956 (good) - 429961 (bad), 56.0.2910.0
https://chromium.googlesource.com/chromium/src/+log/9c175550..1a5f12f0?pretty=fuller

Suspect: r429957 "Update V8 to version 5.6.217"
Suspect in the V8 roll: https://crrev.com/2472063002 "Preparse lazy function parameters"

Debugging in VS2015 with a breakpoint on GetUnexpectedTokenMessage function kinda confirms the suspects as it reveals a callstack that contains code from the suspected CL: https://crrev.com/2472063002/diff2/1:60001/src/parsing/parser.cc#newcode2679

Able to reproduce the issue on latest Chrome stable i.e.,56.0.2924.76 on Windows 7,10, Mac and Linux.

Note : Based on the bisect which was provided on Comment#2 marking the bug as "Blink>JavaScript.

 woxxom@ sorry, I did bisect again and found the same result as you :

Last good build : 56.0.2909.0
First Bad build : 56.0.2910.0

You are probably looking for a change made after 429956 (known good), but no lat
er than 429957 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/9c17555068fd0e9d341ef3b7ac3c5fa6d6ec9126..22225491e169e11297a25d1db962392ca14f8fcd

hablich@ is OOO adding jochen@

cc'ing the CL author and reviewer would be even better!

I can repro this too, but indeed it needs a webserver to repro.

It doesn't repro without streaming ( out/Release/chrome --user-data-dir=/tmp/foo "--js-flags=--no-script-streaming" )

But it's weird that the commit in question would have anything to do with this.

More investigations:

- There's nothing wonky about the file; it starts with a UTF-8 BOM (0xef, 0xbb, 0xbf).
- Removing the byte order mark makes the problem go away.
- Lazy parsing aborting seems to play a role here too!

-> the bug occurs as combination of the lazy parsing aborting + streaming + bom handling. Not sure why that commit in question exposes it.

More information: 

1) the error comes from here:

#2 0x7ff38c44e56d v8::internal::ParserBase<>::ReportClassifierError()
#3 0x7ff38c435fd4 v8::internal::ParserBase<>::ParseFormalParameter()
#4 0x7ff38c435771 v8::internal::ParserBase<>::ParseFormalParameterList()
#5 0x7ff38c442d19 v8::internal::Parser::ParseFunction()
#6 0x7ff38c4385ea v8::internal::Parser::ParseFunctionLiteral()
#7 0x7ff38c4596fb v8::internal::ParserBase<>::ParseMemberExpression()
#8 0x7ff38c4566ca v8::internal::ParserBase<>::ParseLeftHandSideExpression()
#9 0x7ff38c464458 v8::internal::ParserBase<>::ParsePostfixExpression()
#10 0x7ff38c463145 v8::internal::ParserBase<>::ParseBinaryExpression()
#11 0x7ff38c462a35 v8::internal::ParserBase<>::ParseConditionalExpression()
#12 0x7ff38c43b99c v8::internal::ParserBase<>::ParseAssignmentExpression()
#13 0x7ff38c45f95f v8::internal::ParserBase<>::ParseVariableDeclarations()
#14 0x7ff38c43999b v8::internal::ParserBase<>::ParseStatementListItem()
#15 0x7ff38c44f153 v8::internal::ParserBase<>::ParseStatementList()
#16 0x7ff38c433cb0 v8::internal::Parser::DoParseProgram()
#17 0x7ff38c446d97 v8::internal::Parser::ParseOnBackground()
#18 0x7ff38bfb52ee v8::internal::BackgroundParsingTask::Run()

2) this probably got surfaced by the CL in question because we now start lazy parsing where the parameters start and not at the function body. And if we're off by one there, it's bad. If we're off by one where the function starts, the bug gets hidden (since usually there are some whitespace chars surrounding that position).

These CLs move the BOM handling to V8 side: https://codereview.chromium.org/2354973002/
https://codereview.chromium.org/2351943003/

But they mistakenly use 0xfeff as "UTF-8 BOM" even though that's the UTF-16 BOM, and the UTF-8 BOM 0xefbbbf is not handled at all afaics.

I'm not sure how this works at all and why it only goes wrong when applying a bookmark (vogelheim@, you probably have better insights here).

But my guess is that the UTF-8 BOM is weird, since it's only 3 bytes:
11101111 << start of a 4-byte character!
10111011 << continuation character
10111111 << continuation character

and that somehow confuses the UTF-8 handling but in a subtle way.

Omg, I think it's the "incomplete chars between chunks" handling thing that gets confused!

This is what happens at the beginning of the data:

parsing on background
Utf8ExternalStreamingStream::FillBuffer 0
got chunk data 239 << debug print in Utf8ExternalStreamingStream::FillBufferFromCurrentChunk
Utf8::ValueOfIncremental 239 << this is 0xef
got chunk data 187
Utf8::ValueOfIncremental 187 << this is 0xbb
got chunk data 191
Utf8::ValueOfIncremental 191 << this is 0xbf

And this is what happens when we abort the lazy parsing:
lazy parsing aborted
applying bookmark 41
Utf8ExternalStreamingStream::FillBuffer 41
Utf8::ValueOfIncremental 239 << huh, where do these come from??
Utf8::ValueOfIncremental 187
Utf8::ValueOfIncremental 191

So it looks like we're re-processing the BOM after setting the bookmark.

Ah, found it. The bug is that Utf8ExternalStreamingStream::SkipToPosition doesn't process the BOM (like Utf8ExternalStreamingStream::FillBufferFromCurrentChunk does).

The BOM handling itself is correct; checking against the 0xfeff is enough, since the unicode module already converts the UTF-8 bom into it.

Patch will follow soon.

https://codereview.chromium.org/2663773002/

Given that this potentially impacts every web server serving UTF-8, I suggest keeping the RB-Stable label.

Marja, when do you think can you land the fix mentioned in #13?

I can confirm that this is also reproducible on Android with Chrome 56.0.2924.78. 

The files in the bug description need to be hosted on a local web server. After the page loads, the "Uncaught SyntaxError: Unexpected token (" error shows up in the DevTools console.

The bisect I found is also the same as in comment#6.

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

commit d293656481cfefd69dd26301c20e480bb4878b54
Author: marja <marja@chromium.org>
Date: Mon Jan 30 20:18:26 2017

[scanner] Fix bom handling

The bug used to show up when
- we were streaming a script starting with 0xef 0xbb 0xbf
- we aborted preparsing a function (and reset to a bookmark)

BUG= chromium:685618 

Review-Url: https://codereview.chromium.org/2663773002
Cr-Commit-Position: refs/heads/master@{#42790}

[modify] https://crrev.com/d293656481cfefd69dd26301c20e480bb4878b54/src/parsing/scanner-character-streams.cc

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

commit 10bb974ec3e2f0477aab79fab109ef729fd4f82d
Author: vogelheim <vogelheim@chromium.org>
Date: Mon Jan 30 23:21:03 2017

[scanner] Regression test for Utf-8 BOM handling ( crbug.com/685618 ).

The existing unit test explicitly checked for this case, but was - under
the right circumstances - defeated by the optimization to not re-run the
whole position search if we were close enough.

BUG= chromium:685618 

Review-Url: https://codereview.chromium.org/2663883002
Cr-Commit-Position: refs/heads/master@{#42794}

[modify] https://crrev.com/10bb974ec3e2f0477aab79fab109ef729fd4f82d/test/cctest/parsing/test-scanner-streams.cc

It seems that as all patches have been landed, we should have canary coverage by tomorrow, Wednesday at the latest - correct?

If so, we need to arrange for all patches to be merged to M56 branch by Tuesday at 5 PM PT so that the fixes are picked up in our daily M56 build.  Since 5 PM PT is 2 AM in Munich, and I'm unsure of team availability outside of normal business hours, can we please merge the fixes to the M56 branch tomorrow?  That way they can be picked up in tomorrow night's build, we can qualify it Tuesday night, and then ship it Wednesday (assuming canary data comes back OK).

Re #19: SGTM. d293656481cfefd69dd26301c20e480bb4878b54 is on today's Canary and the world does not seem to burn. I will merge it as Marja is not here today.

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

commit 7f31edbbfc708438e02ed0661f7030b07bb64361
Author: Michael Hablich <hablich@chromium.org>
Date: Tue Jan 31 13:08:44 2017

Merged: Squashed multiple commits.

Merged: [scanner] Fix bom handling
Revision: d293656481cfefd69dd26301c20e480bb4878b54

Merged: [scanner] Regression test for Utf-8 BOM handling ( crbug.com/685618 ).
Revision: 10bb974ec3e2f0477aab79fab109ef729fd4f82d

BUG= chromium:685618 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
TBR=jochen@chromium.org, marja@chromium.org, vogelheim@chromium.org

Review-Url: https://codereview.chromium.org/2664183002 .
Cr-Commit-Position: refs/branch-heads/5.6@{#98}
Cr-Branched-From: bdd3886218dfe76e8560eb8a18401942452ae859-refs/heads/5.6.326@{#1}
Cr-Branched-From: 879f6599eee6e1dfcbe9a24bf688b261c03e9558-refs/heads/master@{#41014}

[modify] https://crrev.com/7f31edbbfc708438e02ed0661f7030b07bb64361/src/parsing/scanner-character-streams.cc
[modify] https://crrev.com/7f31edbbfc708438e02ed0661f7030b07bb64361/test/cctest/parsing/test-scanner-streams.cc

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

commit c88efa3a37c2c31b79831746a1a01d23abf9848a
Author: Michael Hablich <hablich@chromium.org>
Date: Tue Jan 31 13:09:49 2017

Merged: Squashed multiple commits.

Merged: [scanner] Fix bom handling
Revision: d293656481cfefd69dd26301c20e480bb4878b54

Merged: [scanner] Regression test for Utf-8 BOM handling ( crbug.com/685618 ).
Revision: 10bb974ec3e2f0477aab79fab109ef729fd4f82d

BUG= chromium:685618 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
TBR=jochen@chromium.org, marja@chromium.org, vogelheim@chromium.org

Review-Url: https://codereview.chromium.org/2667953002 .
Cr-Commit-Position: refs/branch-heads/5.7@{#70}
Cr-Branched-From: 975e9a320b6eaf9f12280c35df98e013beb8f041-refs/heads/5.7.492@{#1}
Cr-Branched-From: 8d76f0e3465a84bbf0bceab114900fbe75844e1f-refs/heads/master@{#42426}

[modify] https://crrev.com/c88efa3a37c2c31b79831746a1a01d23abf9848a/src/parsing/scanner-character-streams.cc
[modify] https://crrev.com/c88efa3a37c2c31b79831746a1a01d23abf9848a/test/cctest/parsing/test-scanner-streams.cc

This is no longer reproducible on 56.0.2924.87 on Android.