Bug 23225 – REGRESSION (r38592-r38645): Assertion failure in reparseInPlace() (m_sourceElements) at sfgate.com

• Component: JavaScriptCore
• Status: RESOLVED FIXED

Visiting the URL with TOT causes
ASSERTION FAILED: m_sourceElements
(JavaScriptCore/parser/Parser.cpp:76 void JSC::Parser::reparseInPlace(JSC::JSGlobalData*, JSC::FunctionBodyNode*))

Backtrace:
#0  0x00b56987 in JSC::Parser::reparseInPlace (this=0x1d1b2d70, globalData=0x6ed3000, functionBodyNode=0x1caefb50) at Parser.cpp:76
#1  0x00b56bb3 in JSC::FunctionBodyNode::generateBytecode (this=0x1caefb50, scopeChainNode=0x1d0de450) at Nodes.cpp:2597
#2  0x00bec93e in JSC::FunctionBodyNode::bytecode (this=0x1caefb50, scopeChain=0x1d0de450) at Nodes.h:2188
#3  0x00bd16a9 in JSC::Interpreter::cti_op_call_JSFunction (args=0x0) at JavaScriptCore/interpreter/Interpreter.cpp:4812
#4  0x00bcad60 in JSC::Interpreter::retrieveCaller () at JavaScriptCore/interpreter/Interpreter.cpp:4019
#5  0x00bece66 in JSC::JIT::execute (code=0x2194ba94, registerFile=0x68e0e34, callFrame=0x1f110048, globalData=0x6ed3000, exception=0xbfffddd0) at JIT.h:351
#6  0x00bd35ee in JSC::Interpreter::execute (this=0x68e0e00, programNode=0x2135a120, callFrame=0x1ea23264, scopeChain=0x1d0de450, thisObj=0x1cfefdc0, exception=0xbfffddd0) at JavaScriptCore/interpreter/Interpreter.cpp:908
#7  0x00b56f5c in JSC::evaluate (exec=0x1ea23264, scopeChain=@0x1ea23220, source=@0xbfffe188, thisValue={m_ptr = 0x1cfefdc0}) at Completion.cpp:67

[Oliver Hunt]

The error appears to occur on line 364 of http://js.zvents.com/javascripts/happy_default.js?43797:

list.push(['<label for="',type.label,'">','<input id="',type.label,'" ',inputSnippet,' class="ZventsNearbyRadio" type="radio" name="ZventsNearbyRadio" value="',type.type,'" ',is.first?'checked="checked" ':'',' onclick="',onclickSnippet,'" />',selectorSnippet,'</label>',].join(''));}});var tab_cols=this.args.columns?this.args.columns:2;return list.length==0?'':['<div class="ZventsNearbySelectWrapper">','<form id="ZventsNearbySelect" class="ZventsNearbyForm" name="ZventsNearbyForm">',list.tabulate({down:true,cols:tab_cols}),'</form>','</div>'].join('');}}};&#65279;

If you examine the source provider it looks like a '?' is being inserted into the source which makes no sense but does bust the js

[David Kilzer (:ddkilzer)]

(In reply to comment #1)
> [...],list.tabulate({down:true,cols:tab_cols}),'</form>','</div>'].join('');}}};&#65279;
> 
> If you examine the source provider it looks like a '?' is being inserted into
> the source which makes no sense but does bust the js

Is it an encoding issue?  That's probably not a normal question mark based on the encoding of the previous comment.

[David Kilzer (:ddkilzer)]

<rdar://problem/6487432>

[Oliver Hunt]

Maybe terminal was just getting confused?

[Oliver Hunt]

You're right, if i  force utf-8, then it shows up as y-with-umlauts: ÿ

[Paul Knight]

Those bytes at the end are actually EF BB BF, the UTF-8 BOM. This sequence shouldn't appear in the middle of the stream.

[Oliver Hunt]

Okay, the wonders of JS mean a byte order marker should be ignored if it appears midway through the content -- the lexer should be skipping it, and if it's skipping it then it shouldn't effect parsing.

That means if this is causing a parse error the reparsing is screwing up and declaring parseable content unparseable.

[Oliver Hunt]

This bug causes the "flags" to be missing on the inset Google map when loaded on a Release build. 

[Oliver Hunt]

Vastly reduced testcase: http://nerget.com/bugs/bug23225.html

[David Kilzer (:ddkilzer)]

The bisect-builds script reports:

Works: r38592  Fails: r38645

[David Kilzer (:ddkilzer)]

(In reply to comment #10)
> The bisect-builds script reports:
> Works: r38592  Fails: r38645

r38635 is the most likely suspect in that range.

http://trac.webkit.org/changeset/38635

[Oliver Hunt]

Well yes, r38635 is the introduction of reparsing :P

[Oliver Hunt]

Created attachment 26761 [details]
Decompose the lexer output from the reparsing

Looking at this, it looks like the something causes us to extend the length of the inner function by one character so that it ends up incorrectly including the final }

[Oliver Hunt]

Okay, have further reduced this test case to 36 bytes and only a single level of functions -- we get the wrong length for a function if immediately following the function we get a bom, although i still don't know the reason for this :-/

[Oliver Hunt]

Got a fix, very simple, just banging out a testcase

[Oliver Hunt]

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	JavaScriptCore/ChangeLog
	M	JavaScriptCore/parser/Lexer.cpp
	M	LayoutTests/ChangeLog
	A	LayoutTests/fast/js/bom-in-file-retains-correct-offset-expected.txt
	A	LayoutTests/fast/js/bom-in-file-retains-correct-offset.html
	A	LayoutTests/fast/js/resources/bom-in-file-retains-correct-offset.js
Committed r39942