RESOLVED FIXED 120015
DFG 32Bit: Crash loading "Classic" site @ translate.google.com 
https://bugs.webkit.org/show_bug.cgi?id=120015
Summary DFG 32Bit: Crash loading "Classic" site @ translate.google.com
Michael Saboff
Reported 2013-08-19 10:33:52 PDT
For 32 bit builds, loading the "Classic" page at translate.google.com crashes in 32 bit builds. On iOS, the stack trace looks something like: 0 JavaScriptCore 0x3085bf60 operationGetByValCell + 148 (WriteBarrier.h:103) 1 ??? 0x25982d8c 0 + 630730124 2 JavaScriptCore 0x307e5ef4 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 52 (CallData.cpp:40) 3 JavaScriptCore 0x308b35f2 JSC::functionProtoFuncCall(JSC::ExecState*) + 186 (FunctionPrototype.cpp:168) 4 ??? 0x258971be 0 + 629764542 5 JavaScriptCore 0x307e5ef4 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 52 (CallData.cpp:40) 6 JavaScriptCore 0x308b35f2 JSC::functionProtoFuncCall(JSC::ExecState*) + 186 (FunctionPrototype.cpp:168) 7 ??? 0x258971be 0 + 629764542 8 JavaScriptCore 0x307e5ef4 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 52 (CallData.cpp:40) 9 JavaScriptCore 0x308b35f2 JSC::functionProtoFuncCall(JSC::ExecState*) + 186 (FunctionPrototype.cpp:168) 10 ??? 0x258971be 0 + 629764542 11 JavaScriptCore 0x307e5ef4 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 52 (CallData.cpp:40) 12 JavaScriptCore 0x308b35f2 JSC::functionProtoFuncCall(JSC::ExecState*) + 186 (FunctionPrototype.cpp:168) 13 ??? 0x258971be 0 + 629764542 14 JavaScriptCore 0x307e5ef4 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 52 (CallData.cpp:40) 15 JavaScriptCore 0x308b34c8 JSC::functionProtoFuncApply(JSC::ExecState*) + 704 (FunctionPrototype.cpp:154) 16 ??? 0x2589713e 0 + 629764414 17 JavaScriptCore 0x308ba4a6 JSC::eval(JSC::ExecState*) + 926 (Interpreter.cpp:198) 18 JavaScriptCore 0x309286ac llint_slow_path_call_eval + 224 (LLIntSlowPaths.cpp:1493) 19 JavaScriptCore 0x3092d990 llint_op_call_eval + 12 20 JavaScriptCore 0x307e5ef4 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 52 (CallData.cpp:40) 21 WebCore 0x37b8f57e WebCore::JSMainThreadExecState::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 142 (JSMainThreadExecState.h:64) 22 WebCore 0x3775b656 WebCore::ScheduledAction::executeFunctionInContext(JSC::JSGlobalObject*, JSC::JSValue, WebCore::ScriptExecutionContext*) + 310 (ScheduledAction.cpp:111) 23 WebCore 0x3775b49c WebCore::ScheduledAction::execute(WebCore::Document*) + 108 (ScheduledAction.cpp:132) 24 WebCore 0x3775b298 WebCore::DOMTimer::fired() + 372 (DOMTimer.cpp:182) 25 WebCore 0x37717f4c WebCore::ThreadTimers::sharedTimerFiredInternal() + 132 (ThreadTimers.cpp:143) 26 WebCore 0x37717e9e WebCore::timerFired(__CFRunLoopTimer*, void*) + 22 (SharedTimerIOS.mm:62) 27 CoreFoundation 0x2f7fa734 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 12 (CFRunLoop.c:1604) 28 CoreFoundation 0x2f7fa34a __CFRunLoopDoTimer + 778 (CFRunLoop.c:2090) <rdar://problem/14644548>
Attachments
Patch (1.84 KB, patch)
2013-08-19 15:09 PDT, Michael Saboff 		oliver: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Michael Saboff
Comment 1 2013-08-19 10:48:09 PDT
The javascript that triggers the problem is: function (){return this.Ad||(this.Ad=so+(this.mb.a++)[Xb](36))} and it's byte code is: [ 0] enter [ 1] convert_this r-7 [ 4] get_by_id r0, r-7, Ad(@id0) [ 13] jtrue r0, 86(->99) [ 16] mov r1, r-7 [ 19] resolve r2, so(@id1), 284206064 [ 24] get_by_id r3, r-7, mb(@id2) [ 33] get_by_id r4, r3, a(@id3) [ 42] to_number r5, r4 [ 45] pre_inc r4 [ 47] put_by_id r3, a(@id3), r4 [ 56] resolve r6, Xb(@id4), 284206076 [ 61] get_by_val r6, r5, r6 Original [ 67] mov r8, r5 [ 70] mov r7, Int32: 36(@k0) [ 73] call r6, 2, 15 status(Not Set) [ 79] call_put_result r6 [ 82] add r2, r2, r6 [ 87] put_by_id r1, Ad(@id0), r2 [ 96] mov r0, r2 [ 99] ret r0 The IR for (this.mb.a++)[Xb], specifically the get_by_val for …[Xb] assumes that the object being index is a Cell, but the processing of (this.mb.a++) is predicting int. Here are the two nodes in question: 34: < 4:8> GetByOffset(KnownCell:@31<Final>, JS|UseAsOther, id3{a}, 1, bc#33) predicting Int 45: <!1:9> GetByVal(Check:Cell:@34<Int32>, @43<String>, JS|MustGen|MightClobber|UseAsOther|CanExit, GenericNonArrayInBoundsAsIs, bc#61) predicting Function SpeculativeJIT::fillSpeculateCell() in DFGSpeculativeJIT32_64.cpp doesn't check for values spilled as DataFormatInteger like the 64 bit version.
Michael Saboff
Comment 2 2013-08-19 15:09:23 PDT
Created attachment 209129 [details] Patch Also cleaned up prior change log that inadvertently included the info from this change.
Oliver Hunt
Comment 3 2013-08-19 15:11:45 PDT
Comment on attachment 209129 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=209129&action=review > Source/JavaScriptCore/ChangeLog:-13 > - * dfg/DFGSpeculativeJIT32_64.cpp: > - (JSC::DFG::SpeculativeJIT::fillSpeculateCell): ?
Michael Saboff
Comment 4 2013-08-19 15:23:30 PDT
(In reply to comment #3) > (From update of attachment 209129 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=209129&action=review > > > Source/JavaScriptCore/ChangeLog:-13 > > - * dfg/DFGSpeculativeJIT32_64.cpp: > > - (JSC::DFG::SpeculativeJIT::fillSpeculateCell): > > ? Like I said in the comment for the attachment. I inadvertently added the changed files to a prior change log. Hazards of handling an interrupting problem in the same checkout.
Michael Saboff
Comment 5 2013-08-19 15:37:48 PDT
Committed r154303: <http://trac.webkit.org/changeset/154303>
Radar WebKit Bug Importer
Comment 6 2013-08-21 16:36:15 PDT
<rdar://problem/14802240>
Note You need to log in before you can comment on or make changes to this bug.