Bug 23225 - REGRESSION (r38592-r38645): Assertion failure in reparseInPlace() (m_sourceElements) at sfgate.com
Summary: REGRESSION (r38592-r38645): Assertion failure in reparseInPlace() (m_sourceEl...
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P1 Normal
Assignee: Oliver Hunt
URL: http://events.sfgate.com/san-francisc...
Keywords: HasReduction, InRadar, Regression
Depends on:
Reported: 2009-01-10 00:52 PST by mitz
Modified: 2009-01-15 13:15 PST (History)
6 users (show)

See Also:

Decompose the lexer output from the reparsing (1.62 KB, text/plain)
2009-01-15 10:49 PST, Oliver Hunt
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2009-01-10 00:52:08 PST
Visiting the URL with TOT causes
ASSERTION FAILED: m_sourceElements
(JavaScriptCore/parser/Parser.cpp:76 void JSC::Parser::reparseInPlace(JSC::JSGlobalData*, JSC::FunctionBodyNode*))

#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
Comment 1 Oliver Hunt 2009-01-10 03:54:07 PST
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
Comment 2 David Kilzer (:ddkilzer) 2009-01-10 13:07:39 PST
(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.
Comment 3 David Kilzer (:ddkilzer) 2009-01-10 13:10:02 PST
Comment 4 Oliver Hunt 2009-01-10 20:25:15 PST
Maybe terminal was just getting confused?
Comment 5 Oliver Hunt 2009-01-10 20:39:02 PST
You're right, if i  force utf-8, then it shows up as y-with-umlauts: ΓΏ
Comment 6 Paul Knight 2009-01-11 15:57:10 PST
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.
Comment 7 Oliver Hunt 2009-01-12 11:40:50 PST
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.
Comment 8 Oliver Hunt 2009-01-13 12:41:39 PST
This bug causes the "flags" to be missing on the inset Google map when loaded on a Release build. 
Comment 9 Oliver Hunt 2009-01-15 08:52:18 PST
Vastly reduced testcase: http://nerget.com/bugs/bug23225.html
Comment 10 David Kilzer (:ddkilzer) 2009-01-15 09:36:40 PST
The bisect-builds script reports:

Works: r38592  Fails: r38645
Comment 11 David Kilzer (:ddkilzer) 2009-01-15 09:43:27 PST
(In reply to comment #10)
> The bisect-builds script reports:
> Works: r38592  Fails: r38645

r38635 is the most likely suspect in that range.

Comment 12 Oliver Hunt 2009-01-15 09:50:21 PST
Well yes, r38635 is the introduction of reparsing :P
Comment 13 Oliver Hunt 2009-01-15 10:49:39 PST
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 }
Comment 14 Oliver Hunt 2009-01-15 10:58:38 PST
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 :-/
Comment 15 Oliver Hunt 2009-01-15 12:18:16 PST
Got a fix, very simple, just banging out a testcase
Comment 16 Oliver Hunt 2009-01-15 13:15:51 PST
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