Bug 19413 - REGRESSION(r34273): ASSERTION FAILED: startingLineNumber > 0 with PAC file
Summary: REGRESSION(r34273): ASSERTION FAILED: startingLineNumber > 0 with PAC file
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-06 10:55 PDT by Eric Seidel (no email)
Modified: 2012-09-26 12:47 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2008-06-06 10:55:06 PDT
TOT WebKit hits ASSERT loading Google's internal homepage. :(

ASSERTION FAILED: startingLineNumber > 0
(/Users/eseidel/Projects/WebKit/JavaScriptCore/kjs/Parser.cpp:70 void KJS::Parser::parse(KJS::ExecState*, const KJS::UString&, int, WTF::PassRefPtr<KJS::SourceProvider>, int*, int*, KJS::UString*))

I can see if I can create a reduction for you.
Comment 1 Eric Seidel (no email) 2008-06-06 10:56:06 PDT
Actually, looks like it's due to Google's PAC file:

Thread 3 Crashed:
0   com.apple.JavaScriptCore      	0x004a1b2b KJS::Parser::parse(KJS::ExecState*, KJS::UString const&, int, WTF::PassRefPtr<KJS::SourceProvider>, int*, int*, KJS::UString*) + 243 (Parser.cpp:70)
1   com.apple.JavaScriptCore      	0x004e9a89 WTF::PassRefPtr<KJS::ProgramNode> KJS::Parser::parse<KJS::ProgramNode>(KJS::ExecState*, KJS::UString const&, int, WTF::PassRefPtr<KJS::SourceProvider>, int*, int*, KJS::UString*) + 103 (Parser.h:88)
2   com.apple.JavaScriptCore      	0x004a1f9e KJS::Interpreter::checkSyntax(KJS::ExecState*, KJS::UString const&, int, WTF::PassRefPtr<KJS::SourceProvider>) + 118 (interpreter.cpp:52)
3   com.apple.JavaScriptCore      	0x004a20cd KJS::Interpreter::checkSyntax(KJS::ExecState*, KJS::UString const&, int, KJS::UString const&) + 79 (interpreter.cpp:42)
4   com.apple.JavaScriptCore      	0x004ea77d JSCheckScriptSyntax + 221 (JSBase.cpp:72)
5   com.apple.CFNetwork           	0x94b2d2e9 JSCheckScriptSyntax + 202
6   com.apple.CFNetwork           	0x94b16959 _createJSRuntime + 150
7   com.apple.CFNetwork           	0x94b18548 _JSSetEnvironmentForPAC + 129
8   com.apple.CFNetwork           	0x94b18857 _JSFindProxyForURL + 324
9   com.apple.CFNetwork           	0x94ada881 _CFNetworkProxyListForURLAsync + 788
10  com.apple.CFNetwork           	0x94ae7fb1 httpProtocolStart + 608
11  com.apple.CFNetwork           	0x94ad7ea0 CFURLProtocolStartLoad + 28
12  com.apple.CFNetwork           	0x94ad7cb2 _CFURLConnectionProcessServerEvents + 664
13  com.apple.CFNetwork           	0x94ad60d9 muxerSourcePerform + 283
14  com.apple.CoreFoundation      	0x903bd62e CFRunLoopRunSpecific + 3166
15  com.apple.CoreFoundation      	0x903bdd18 CFRunLoopRunInMode + 88
16  com.apple.Foundation          	0x950faac0 +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] + 320
17  com.apple.Foundation          	0x950975ad -[NSThread main] + 45
18  com.apple.Foundation          	0x95097154 __NSThread__main__ + 308
19  libSystem.B.dylib             	0x94e0cc55 _pthread_start + 321
20  libSystem.B.dylib             	0x94e0cb12 thread_start + 34
Comment 2 Timothy Hatcher 2008-06-06 11:13:32 PDT
I think we might want to still allow callers of JSCheckScriptSyntax and JSEvaluateScript to pass whatever starting line number they want. And only have the ASSERT for our internal uses.
Comment 3 Eric Seidel (no email) 2008-06-09 22:53:51 PDT
I've commented out the ASSERT locally so I can actually use Debug WebKit.  It's impossible to use Debug WebKit for anyone who has a PAC file atm. 
Comment 4 Eric Seidel (no email) 2008-06-17 13:30:34 PDT
Removed the ASSERT in:
http://trac.webkit.org/changeset/34628

I guess we can keep this bug around for adding back a proper working ASSERT.
Comment 5 Gavin Barraclough 2012-09-26 12:47:24 PDT
This assert no longer exists.  If you are still seeing a problem using PAC files, please feel free to reopen with a new backtrace.