utf-16 characters in script comments cause DCHECK failure when there is no newline at the end of the file |
|||||
Issue descriptionVersion: HEAD (local build in clean client) OS: Linux What steps will reproduce the problem? (1) Build a chrome debug build, run it (2) Open the attached html file What is the expected output? No DCHECK failure What do you see instead? DCHECK failure at https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/parsing/parser.cc&l=851 # # Fatal error in ../../v8/src/parsing/parser.cc, line 851 # Check failed: scanner_.peek_location().beg_pos == source->length() (29 vs. 28). # - If there is a utf-16 character present in the file, and there is no newline at the end of the file, this DCHECK fails - If the utf-16 character is present, and there is a newline at the end of the file, the DCHECK does not fail - If there is no utf-16 character present, and there is no newline at the end of the file, the DCHECK does not fail I've attached html and js files demonstrating these three case.
,
Apr 29 2016
,
Apr 29 2016
,
Jul 14 2016
I can't reproduce this. meade, can you still reproduce this DCHECK?
,
Jul 15 2016
I can't reproduce this any more either. I guess it's been fixed somewhere along the way. The original website I found this problem on also doesn't trigger the issue anymore either.
,
Jul 15 2016
There was a fix in May, where parsing would DCHECK-fail at the last character of the stream, if that character was a part of certain tokens (but not whitespace). This sounds like a duplicate. fix: crrev.com/1941843002 bug: crbug.com/607903 @meade: Thanks for the report. The other bug was a ClusterFuzz thing. I'm happy and/or mildly shocked whenever I find out those things happen on real pages, too. :)
,
Jul 19 2016
@vogelheim: No problem! I'm glad it got caught by clusterfuzz and was fixed intentionally! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by meade@chromium.org
, Apr 18 2016