Bug 148380 – Web Inspector: REGRESSION: JSC crashes when pausing at console.assert statement

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

[Blaze Burg]

Created attachment 259756 [details]
test case

STEPS TO REPRODUCE:

1. Open the attached test case.
2. Open Web Inspector
3. Open Inspector^2 (Right-click and "Inspecto Element" in the Web Inspector, if the option doesn't exist follow steps here: http://trac.webkit.org/wiki/WebInspectorDebugging)
4. In Debugger tab, enable "Break on [All] Exceptions".
5. Set a breakpoint in Inspector^1 at the line with `console.assert(...)`.
6. Reload the inspected page.

EXPECTED:

 * Should pause at console.assert line but not at the breakpoint, because of Step (4).

ACTUAL:

 * Crashes with this callstack (100% reproducible on my machine)

--


Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000000bbadbeef

VM Regions Near 0xbbadbeef:
--> 
    __TEXT                 0000000106d1c000-0000000106d1e000 [    8K] r-x/rwx SM=COW  /Users/USER/*/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.Development.xpc/Contents/MacOS/com.apple.WebKit.WebContent.Development

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.JavaScriptCore      	0x000000010d326fbe WTFCrash + 62
1   com.apple.JavaScriptCore      	0x000000010cd2b348 JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult(JSC::CompilationResult) + 776
2   com.apple.JavaScriptCore      	0x000000010d09af9c JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete(JSC::CodeBlock*, JSC::CompilationResult) + 140
3   com.apple.JavaScriptCore      	0x000000010cf31691 JSC::DFG::Worklist::completeAllReadyPlansForVM(JSC::VM&, JSC::DFG::CompilationKey) + 257
4   com.apple.JavaScriptCore      	0x000000010cf318ce JSC::DFG::Worklist::completeAllPlansForVM(JSC::VM&) + 62
5   com.apple.JavaScriptCore      	0x000000010cf32ca8 JSC::DFG::completeAllPlansForVM(JSC::VM&) + 56
6   com.apple.JavaScriptCore      	0x000000010cd6852c JSC::Debugger::exception(JSC::ExecState*, JSC::JSValue, bool) + 108
7   com.apple.JavaScriptCore      	0x000000010d043475 JSC::Interpreter::unwind(void*&, JSC::ExecState*&, JSC::Exception*) + 325
8   com.apple.JavaScriptCore      	0x000000010d06149a JSC::genericUnwind(JSC::VM*, JSC::ExecState*) + 90
9   com.apple.JavaScriptCore      	0x000000010d19c41d llint_slow_path_handle_exception + 45
10  com.apple.JavaScriptCore      	0x000000010d1a420a llint_entry + 15423
11  com.apple.JavaScriptCore      	0x000000010d1a5efd llint_entry + 22834
12  com.apple.JavaScriptCore      	0x000000010d1a03bb vmEntryToJavaScript + 326
13  com.apple.JavaScriptCore      	0x000000010d05fbe9 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 169
14  com.apple.JavaScriptCore      	0x000000010d0464da JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 474
15  com.apple.JavaScriptCore      	0x000000010cd12a0e JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 62
16  com.apple.JavaScriptCore      	0x000000010d2d31ce JSC::JSJobMicrotask::run(JSC::ExecState*) + 734
17  com.apple.WebCore             	0x000000010de24add WebCore::JSGlobalObjectCallback::call() + 189 (JSMainThreadExecState.h:93)
18  com.apple.WebCore             	0x000000010d9eaf31 std::__1::__function::__func<WebCore::Document::postTask(WebCore::ScriptExecutionContext::Task)::$_0, std::__1::allocator<WebCore::Document::postTask(WebCore::ScriptExecutionContext::Task)::$_0>, void ()>::operator()() + 113 (memory:2624)
19  com.apple.JavaScriptCore      	0x000000010d33f97d WTF::dispatchFunctionsFromMainThread() + 525
20  com.apple.Foundation          	0x00007fff8941cdd0 __NSThreadPerformPerform + 293
21  com.apple.CoreFoundation      	0x00007fff8ed5da01 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
22  com.apple.CoreFoundation      	0x00007fff8ed4fb8d __CFRunLoopDoSources0 + 269
23  com.apple.CoreFoundation      	0x00007fff8ed4f1bf __CFRunLoopRun + 927
24  com.apple.CoreFoundation      	0x00007fff8ed4ebd8 CFRunLoopRunSpecific + 296
25  com.apple.HIToolbox           	0x00007fff890b656f RunCurrentEventLoopInMode + 235
26  com.apple.HIToolbox           	0x00007fff890b62ea ReceiveNextEventCommon + 431
27  com.apple.HIToolbox           	0x00007fff890b612b _BlockUntilNextEventMatchingListInModeWithFilter + 71
28  com.apple.AppKit              	0x00007fff852938ab _DPSNextEvent + 978
29  com.apple.AppKit              	0x00007fff85292e58 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
30  com.apple.AppKit              	0x00007fff85288af3 -[NSApplication run] + 594
31  com.apple.AppKit              	0x00007fff85205244 NSApplicationMain + 1832
32  libxpc.dylib                  	0x00007fff9295f928 _xpc_objc_main + 793
33  libxpc.dylib                  	0x00007fff92961030 xpc_main + 490
34  com.apple.WebKit.WebContent.Development	0x0000000106d1d675 main + 21 (XPCServiceMain.Development.mm:90)
35  libdyld.dylib                 	0x00007fff8cff55c9 start + 1

[Geoffrey Garen]

I can't seem to reproduce this using Spade-188767-74819.

[Blaze Burg]

Possibly useful message that got dumped to console:

toLength#CIvpti:[0x121ad8250->0x113499800, BaselineFunctionCall, 66 (StrictMode) (FTLFail)]: we have result = CompilationSuccessful but we are our own replacement.

[Blaze Burg]

I was able to reproduce this with a build from Sunday, prior to ggaren's two patches being rolled back in. So this might be unrelated to those patches after all.

Another one:

readToken#AvwLUZ:[0x12822a250->0x119dc5f00, BaselineFunctionCall, 388 (StrictMode) (FTLFail)]: we have result = CompilationSuccessful but we are our own replacement.

[Blaze Burg]

Created attachment 260288 [details]
better test case

[Blaze Burg]

Simpler steps to reproduce:

STEPS TO REPRODUCE:

1. Open the attached test case.
2. Open Web Inspector
3. In Debugger tab, enable "Break on [All] Exceptions" (at the top of the left sidebar).
4. Set a breakpoint at the line with `console.assert(...)`.
5. Reload the inspected page.

EXPECTED:

 * Should pause at at the breakpoint. Breakpoint should be hit before evaluating console.assert, which also pauses the debugger.

ACTUAL:

 * Crashes with this callstack in Debugger::pause underneath evaluating console.assert.

--

[Blaze Burg]

I have bisected the regression to this commit:

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

Please advise whether this can be fixed quickly or it should be rolled out for further analysis.

[Geoffrey Garen]

I still can't seem to reproduce this crash, using a debug or release build. Is there anything special to how you toggle breakpoints or reload the page?

I can't promise a quick fix if I can't reproduce the crash -- but I also don't think the original patch will roll out cleanly :(.

[Blaze Burg]

After a full rebuild on ToT, no longer able to reproduce. Closing for now.

[Blaze Burg]

Saam was able to reproduce this last night on TOT.

[Radar WebKit Bug Importer]

<rdar://problem/22527158>

[Saam Barati]

This no longer crashes for me