Bug 24086 – Regression (r40993): WebKit crashes after logging in to lists.zenbe.com

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Kevin Ballard]

The latest WebKit nightly (r41128) crashes 100% of the time after logging in to lists.zenbe.com. Crash was confirmed by pewtermoose in #webkit.

[Matt Lilek]

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)

[Kevin Ballard]

This bug has made it into the Safari 4 beta. Quite unfortunate.

[Cameron Zwarich (cpst)]

That's too bad, Kevin. :-(

I'll try to reduce this today, so I can fix it.

[Cameron Zwarich (cpst)]

I'm in the middle of reducing the JS from the page. It's still about 10 000 lines.

[Cameron Zwarich (cpst)]

Created attachment 27953 [details]
Partial reduction

Here is a partial reduction of the crash. It is still about 5700 lines.

[Cameron Zwarich (cpst)]

Created attachment 27960 [details]
Further reduction

[Cameron Zwarich (cpst)]

Created attachment 27985 [details]
Further reduction

[Cameron Zwarich (cpst)]

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.

[Cameron Zwarich (cpst)]

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.

[Mark Rowe (bdash)]

<rdar://problem/6625111>

[Cameron Zwarich (cpst)]

Fixed in r41243.