Bug 24086 - Regression (r40993): WebKit crashes after logging in to lists.zenbe.com
Summary: Regression (r40993): WebKit crashes after logging in to lists.zenbe.com
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.5
: P1 Normal
Assignee: Cameron Zwarich (cpst)
URL: http://lists.zenbe.com
Keywords: InRadar, NeedsReduction, Regression
Depends on:
Blocks:
 
Reported: 2009-02-22 21:20 PST by Kevin Ballard
Modified: 2009-02-25 23:05 PST (History)
3 users (show)

See Also:


Attachments
Partial reduction (118.05 KB, text/html)
2009-02-24 18:34 PST, Cameron Zwarich (cpst)
no flags Details
Further reduction (77.60 KB, text/html)
2009-02-24 23:38 PST, Cameron Zwarich (cpst)
no flags Details
Further reduction (41.05 KB, text/html)
2009-02-25 14:29 PST, Cameron Zwarich (cpst)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Ballard 2009-02-22 21:20:55 PST
The latest WebKit nightly (r41128) crashes 100% of the time after logging in to lists.zenbe.com. Crash was confirmed by pewtermoose in #webkit.
Comment 1 Matt Lilek 2009-02-22 22:01:31 PST
Confirmed with r41128 debug build, also crashes with same backtrace when adding a second item to a list:

Thread 0 Crashed:
0   ???                           	0000000000 0 + 0
1   com.apple.JavaScriptCore      	0x0056a126 JSC::JITCode::execute(JSC::RegisterFile*, JSC::ExecState*, JSC::JSGlobalData*, JSC::JSValuePtr*) + 58 (JITCode.h:86)
2   com.apple.JavaScriptCore      	0x00553dae JSC::Interpreter::execute(JSC::FunctionBodyNode*, JSC::ExecState*, JSC::JSFunction*, JSC::JSObject*, JSC::ArgList const&, JSC::ScopeChainNode*, JSC::JSValuePtr*) + 888 (Interpreter.cpp:730)
3   com.apple.JavaScriptCore      	0x004a4589 JSC::JSFunction::call(JSC::ExecState*, JSC::JSValuePtr, JSC::ArgList const&) + 139 (JSFunction.cpp:83)
4   com.apple.JavaScriptCore      	0x004a4642 JSC::call(JSC::ExecState*, JSC::JSValuePtr, JSC::CallType, JSC::CallData const&, JSC::JSValuePtr, JSC::ArgList const&) + 178 (CallData.cpp:39)
5   com.apple.JavaScriptCore      	0x004b3390 __ZN3JSCL22functionProtoFuncApplyEPNS_9ExecStateEPNS_8JSObjectENS_10JSValuePtrERKNS_7ArgListE + 686 (FunctionPrototype.cpp:125)
6   com.apple.JavaScriptCore      	0x0058b042 JSC::JITStubs::cti_op_call_NotJSFunction(void*, ...) + 534 (JITStubs.cpp:957)
7   com.apple.JavaScriptCore      	0x0058515e jscGeneratedNativeCode + 0 (JITStubs.cpp:238)
8   com.apple.JavaScriptCore      	0x0056a126 JSC::JITCode::execute(JSC::RegisterFile*, JSC::ExecState*, JSC::JSGlobalData*, JSC::JSValuePtr*) + 58 (JITCode.h:86)
9   com.apple.JavaScriptCore      	0x00553dae JSC::Interpreter::execute(JSC::FunctionBodyNode*, JSC::ExecState*, JSC::JSFunction*, JSC::JSObject*, JSC::ArgList const&, JSC::ScopeChainNode*, JSC::JSValuePtr*) + 888 (Interpreter.cpp:730)
Comment 2 Kevin Ballard 2009-02-24 11:16:35 PST
This bug has made it into the Safari 4 beta. Quite unfortunate.
Comment 3 Cameron Zwarich (cpst) 2009-02-24 11:23:16 PST
That's too bad, Kevin. :-(

I'll try to reduce this today, so I can fix it.
Comment 4 Cameron Zwarich (cpst) 2009-02-24 15:13:47 PST
I'm in the middle of reducing the JS from the page. It's still about 10 000 lines.
Comment 5 Cameron Zwarich (cpst) 2009-02-24 18:34:40 PST
Created attachment 27953 [details]
Partial reduction

Here is a partial reduction of the crash. It is still about 5700 lines.
Comment 6 Cameron Zwarich (cpst) 2009-02-24 23:38:09 PST
Created attachment 27960 [details]
Further reduction
Comment 7 Cameron Zwarich (cpst) 2009-02-25 14:29:26 PST
Created attachment 27985 [details]
Further reduction
Comment 8 Cameron Zwarich (cpst) 2009-02-25 21:01:36 PST
Here's a reduction that only works with commandline jsc, compiled with all extra JIT optimizations off:

function f()
{
}

[].sort(f);
f();

It doesn't crash with caching of calls turned on. This more complicated example crashes with caching of calls enabled:

function f() { } [].sort(f); function g() { } function h(x) { x(); } h(g); h(g); h(g); h(f);

This is caused by r40993:

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

This patch creates CodeBlocks with no JIT code, breaking an assumption in the function call logic.
Comment 9 Cameron Zwarich (cpst) 2009-02-25 21:13:34 PST
Gavin and I talked about it a bit and we agree that the best fix is to simply generate JIT code whenever we optimize numeric sorts. The question is whether to add this as an ad-hoc thing at the end of isNumericCompareFunction() or to encapsulate it in FunctionBodyNode in some way.
Comment 10 Mark Rowe (bdash) 2009-02-25 22:48:54 PST
<rdar://problem/6625111>
Comment 11 Cameron Zwarich (cpst) 2009-02-25 23:05:12 PST
Fixed in r41243.