Bug 141098 – Google doc spreadsheet reproducibly crashes when sorting

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Gavin Sherlock]

Created attachment 245739 [details]
crash log

Step 1.  Go to a google spreadsheet
Step 2.  Sort the spreadsheet by one of the columns

Expected:  Spreadsheet sorts
Actual: tab crashes

Happens reproducibly, in the latest Safari released on OS X Yosemite - Version 8.0.3 (10600.3.18), and on the latest nightly build (r179398).  The fact that it crashes in release safari makes it a showstopper for me.  Relevant part of attached crash log is below.  I don't really want to put the google doc in the public domain, but email me privately if you need access to a copy to reproduce.

Thread 23 Crashed:: WebCore: Worker
0   com.apple.JavaScriptCore      	0x0000000110149317 llint_entry + 4863
1   com.apple.JavaScriptCore      	0x0000000110147e08 vmEntryToJavaScript + 326
2   com.apple.JavaScriptCore      	0x0000000110040a29 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 169
3   com.apple.JavaScriptCore      	0x000000011002160d JSC::Interpreter::execute(JSC::EvalExecutable*, JSC::ExecState*, JSC::JSValue, JSC::JSScope*) + 1613
4   com.apple.JavaScriptCore      	0x0000000110020f80 JSC::eval(JSC::ExecState*) + 2512
5   com.apple.JavaScriptCore      	0x00000001101435c1 llint_slow_path_call_eval + 273
6   com.apple.JavaScriptCore      	0x000000011014da0b llint_entry + 23027
7   com.apple.JavaScriptCore      	0x000000011014d6bc llint_entry + 22180
8   com.apple.JavaScriptCore      	0x000000011014d6bc llint_entry + 22180
9   ???                           	0x00003ab311785af5 0 + 64540766657269
10  ???                           	0x00003ab3117854d6 0 + 64540766655702
11  ???                           	0x00003ab311780c1e 0 + 64540766637086
12  ???                           	0x00003ab311782474 0 + 64540766643316
13  ???                           	0x00003ab311785240 0 + 64540766655040
14  com.apple.JavaScriptCore      	0x0000000110147e08 vmEntryToJavaScript + 326
15  com.apple.JavaScriptCore      	0x0000000110040a29 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 169
16  com.apple.JavaScriptCore      	0x000000011002500d JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 477
17  com.apple.JavaScriptCore      	0x000000010fdad3cf JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, JSC::JSValue*) + 63
18  com.apple.WebCore             	0x0000000110b127de WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) + 1134
19  com.apple.WebCore             	0x00000001107a00ac WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1ul, WTF::CrashOnOverflow>&) + 652
20  com.apple.WebCore             	0x000000011079fd4f WebCore::EventTarget::fireEventListeners(WebCore::Event*) + 239
21  com.apple.WebCore             	0x000000011079fc45 WebCore::EventTarget::dispatchEvent(WTF::PassRefPtr<WebCore::Event>) + 85
22  com.apple.WebCore             	0x0000000111383b87 WebCore::XMLHttpRequestProgressEventThrottle::dispatchEvent(WTF::PassRefPtr<WebCore::Event>) + 199
23  com.apple.WebCore             	0x0000000111383c18 WebCore::XMLHttpRequestProgressEventThrottle::dispatchReadyStateChangeEvent(WTF::PassRefPtr<WebCore::Event>, WebCore::ProgressEventAction) + 56
24  com.apple.WebCore             	0x000000011137f168 WebCore::XMLHttpRequest::callReadyStateChangeListener() + 168
25  com.apple.WebCore             	0x0000000111383339 WebCore::XMLHttpRequest::didReceiveData(char const*, int) + 1465
26  com.apple.WebCore             	0x000000011136a8b3 std::__1::__function::__func<WebCore::WorkerThreadableLoader::MainThreadBridge::didReceiveData(char const*, int)::$_5, std::__1::allocator<WebCore::WorkerThreadableLoader::MainThreadBridge::didReceiveData(char const*, int)::$_5>, void (WebCore::ScriptExecutionContext&)>::operator()(WebCore::ScriptExecutionContext&) + 35
27  com.apple.WebCore             	0x0000000111364a68 WebCore::WorkerRunLoop::runInMode(WebCore::WorkerGlobalScope*, WebCore::ModePredicate const&, WebCore::WorkerRunLoop::WaitMode) + 216
28  com.apple.WebCore             	0x0000000111364940 WebCore::WorkerRunLoop::run(WebCore::WorkerGlobalScope*) + 112
29  com.apple.WebCore             	0x0000000111368401 WebCore::WorkerThread::workerThread() + 657
30  com.apple.JavaScriptCore      	0x00000001102c5f23 WTF::threadEntryPoint(void*) + 179
31  com.apple.JavaScriptCore      	0x00000001102c640f WTF::wtfThreadEntryPoint(void*) + 15
32  libsystem_pthread.dylib       	0x00007fff94aa0268 _pthread_body + 131
33  libsystem_pthread.dylib       	0x00007fff94aa01e5 _pthread_start + 176
34  libsystem_pthread.dylib       	0x00007fff94a9e41d thread_start + 13

[Radar WebKit Bug Importer]

<rdar://problem/19673627>

[Geoffrey Garen]

Can you supply an example spreadsheet that causes this crash when viewed and sorted?

[Gavin Sherlock]

Shared a google spreadsheet with you that has the behavior.  I couldn't successfully reduce it unfortunately.

[Geoffrey Garen]

Thanks! I can reproduce this crash now.

[Michael Saboff]

Created attachment 246503 [details]
Patch

This fixes the crash.  Now we throw an out of stack exception.  There is still an issue with the webpage after the fix.  Now a dialog pops up after the sort completes saying the File is unavailable and that there was a problem.  This is probably due to the out of stack exception.

[Oliver Hunt]

Comment on attachment 246503 [details]
Patch

R=me we should work out what is causing the pathological growth in intermediates. I suspect we're trying to simplify something else in a bad way :(

[Michael Saboff]

Committed r180060: <http://trac.webkit.org/changeset/180060>

[Csaba Osztrogonác]

(In reply to comment #7)
> Committed r180060: <http://trac.webkit.org/changeset/180060>

It broke the cloop bot:

2015-02-13 10:59:03.659 testapi[3268:12127526] Testing Objective-C API
testAPI completed with rc=11 (254)

[Michael Saboff]

(In reply to comment #8)
> (In reply to comment #7)
> > Committed r180060: <http://trac.webkit.org/changeset/180060>
> 
> It broke the cloop bot:
> 
> 2015-02-13 10:59:03.659 testapi[3268:12127526] Testing Objective-C API
> testAPI completed with rc=11 (254)

Looking at the loop now.

[Brent Fulgham]

It looks like this may have broken JSC tests on Windows (one test):

** The following JSC stress test failures have been introduced:
	jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint

[Michael Saboff]

(In reply to comment #10)
> It looks like this may have broken JSC tests on Windows (one test):
> 
> ** The following JSC stress test failures have been introduced:
> 	jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint

That is the new test.

[Michael Saboff]

Here is the Windows test failure from the log:

jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint: Regression test for https://webkit.org/b/141098. Make sure eval() properly handles running out of stack space. This test should run without crashing.
jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint: 
jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint: On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint: 
jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint: 
jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint: test_script_9825: line 2:  1584 Segmentation fault      "$@" ../../../../.vm/JavaScriptCore.framework/Resources/jsc --useFTLJIT\=false --enableFunctionDotArguments\=true --useLLInt\=false resources/standalone-pre.js regress-141098.js resources/standalone-post.js
jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint: ERROR: Unexpected exit code: 139
FAIL: jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint

[Michael Saboff]

Need to fix the C Loop and Windows as noted above.

[Michael Saboff]

Windows / Baseline crash tracked in https://bugs.webkit.org/show_bug.cgi?id=141577 and landed with change set r180083: <http://trac.webkit.org/changeset/180083>.

C Loop issue tracked in https://bugs.webkit.org/show_bug.cgi?id=141671

Similar issue in DFG discovered via code inspection and tracked in https://bugs.webkit.org/show_bug.cgi?id=141676.

[Michael Saboff]

Closing this defect as the primary issue is resolved for non-C Loop builds.

The C Loop issue is tracked in https://bugs.webkit.org/show_bug.cgi?id=141671