RESOLVED INVALID 65060
REGRESSION: cnn.com continually crashes WebProcess 
https://bugs.webkit.org/show_bug.cgi?id=65060
Summary REGRESSION: cnn.com continually crashes WebProcess
Jon
Reported 2011-07-22 20:10:24 PDT
In ToT r91628 running in Safari on 10.7, cnn.com crashes at the end of its load, causing the WebProcess to respawn and crash again until Safari shows an error. This doesn't not occur in Safari 5.1 as it shipped on Lion. Nice demo of WebKit2's crash resilience though! Here's the log: Process: WebProcess [60282] Path: /Users/USER/*/WebKit2.framework/WebProcess.app/Contents/MacOS/WebProcess Identifier: com.apple.WebProcess Version: 535+ (535.1+) Code Type: X86-64 (Native) Parent Process: Safari [60274] Date/Time: 2011-07-22 23:05:52.733 -0400 OS Version: Mac OS X 10.7 (11A511) Report Version: 9 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000000538fc06 VM Regions Near 0x538fc06: --> __TEXT 000000010196f000-0000000101970000 [ 4K] r-x/rwx SM=COW /Users/USER/*/WebKit2.framework/WebProcess.app/Contents/MacOS/WebProcess Application Specific Information: objc[60282]: garbage collection is OFF Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.JavaScriptCore 0x0000000101f246cb JSC::JSValue::toString(JSC::ExecState*) const + 251 (JSString.h:636) 1 com.apple.JavaScriptCore 0x0000000101ff1836 _ZN3JSCL6encodeEPNS_9ExecStateEPKc + 86 (JSGlobalObjectFunctions.cpp:54) 2 com.apple.JavaScriptCore 0x0000000101ff1b1d JSC::globalFuncEncodeURIComponent(JSC::ExecState*) + 13 (JSGlobalObjectFunctions.cpp:529) 3 ??? 0x00002446bda011e8 0 + 39886247694824 4 com.apple.JavaScriptCore 0x0000000101f9a266 JSC::Interpreter::execute(JSC::CallFrameClosure&) + 166 (JSValueInlineMethods.h:402) 5 com.apple.JavaScriptCore 0x0000000101f20cc8 _ZN3JSCL21arrayProtoFuncForEachEPNS_9ExecStateE + 952 (CachedCall.h:51) 6 ??? 0x00002446bda011e8 0 + 39886247694824 7 com.apple.JavaScriptCore 0x0000000101f9a266 JSC::Interpreter::execute(JSC::CallFrameClosure&) + 166 (JSValueInlineMethods.h:402) 8 com.apple.JavaScriptCore 0x0000000101f20cc8 _ZN3JSCL21arrayProtoFuncForEachEPNS_9ExecStateE + 952 (CachedCall.h:51) 9 ??? 0x00002446bda011e8 0 + 39886247694824 10 com.apple.JavaScriptCore 0x0000000101f994ba JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 1306 (JSValueInlineMethods.h:402) 11 com.apple.JavaScriptCore 0x0000000101f38d4a JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 42 (CallData.cpp:40) 12 com.apple.WebCore 0x00000001026fd996 WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) + 1190 (JSMainThreadExecState.h:51) 13 com.apple.WebCore 0x000000010247b205 WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1ul>&) + 149 (EventTarget.cpp:365) 14 com.apple.WebCore 0x000000010247b0c4 WebCore::EventTarget::dispatchEvent(WTF::PassRefPtr<WebCore::Event>) + 164 (Event.h:156) 15 com.apple.WebCore 0x000000010243a420 WebCore::DOMWindow::postMessageTimerFired(WTF::PassOwnPtr<WebCore::PostMessageTimer>) + 256 (DOMWindow.cpp:857) 16 com.apple.WebCore 0x000000010243ddbc WebCore::PostMessageTimer::fired() + 28 (DOMWindow.cpp:143) 17 com.apple.WebCore 0x0000000102bad7a4 WebCore::ThreadTimers::sharedTimerFiredInternal() + 148 (ThreadTimers.cpp:117) 18 com.apple.WebCore 0x0000000102ac0df3 _ZN7WebCoreL10timerFiredEP16__CFRunLoopTimerPv + 51 (SharedTimerMac.mm:167) 19 com.apple.CoreFoundation 0x00007fff91797694 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 20 com.apple.CoreFoundation 0x00007fff917971e6 __CFRunLoopDoTimer + 534 21 com.apple.CoreFoundation 0x00007fff91777ba1 __CFRunLoopRun + 1617 22 com.apple.CoreFoundation 0x00007fff91777216 CFRunLoopRunSpecific + 230 23 com.apple.HIToolbox 0x00007fff92a294ff RunCurrentEventLoopInMode + 277 24 com.apple.HIToolbox 0x00007fff92a30c21 ReceiveNextEventCommon + 355 25 com.apple.HIToolbox 0x00007fff92a30aae BlockUntilNextEventMatchingListInMode + 62 26 com.apple.AppKit 0x00007fff960b8191 _DPSNextEvent + 659 27 com.apple.AppKit 0x00007fff960b7a95 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 28 com.apple.AppKit 0x00007fff960b43d6 -[NSApplication run] + 463 29 com.apple.WebKit2 0x0000000101b5e9bc WebKit::WebProcessMain(WebKit::CommandLine const&) + 710 (WebProcessMainMac.mm:118) 30 com.apple.WebKit2 0x0000000101b366b3 WebKitMain + 291 (WebKitMain.cpp:50) 31 com.apple.WebProcess 0x000000010196fdb8 start + 52
Attachments
Add attachment proposed patch, testcase, etc.
Jon
Comment 1 2011-07-22 23:54:27 PDT
I'll work on a reduction more later, but it does seem that if I copy the cnn.com source to a local html file, ToT no longer crashes. Perhaps that means the issue lies in one of the relatively included files.
Filip Pizlo
Comment 2 2011-07-25 12:44:23 PDT
Unable to reproduce in r91694. Tried both single-process window and multi-process window; no crash either way. Tried opening more tabs of cnn.com, still no crash. Will continue to investigate, but I'm not seeing it right now.
Jon
Comment 3 2011-07-25 14:52:18 PDT
Sorry, this appears to be a clang issue, with my local builds crashing but the 91677 nightly working fine. Using the official nightly also appears to fix my issue with form filling not working. Sorry again. P.S. I get this log message when launching the nightly: 7/25/11 5:31:53.447 PM com.apple.launchd.peruser.501: ([0x0-0x13b13b].org.webkit.nightly.WebKit[95248]) Tried to setup shared memory more than once
Filip Pizlo
Comment 4 2011-07-25 14:55:22 PDT
(In reply to comment #3) > Sorry, this appears to be a clang issue, with my local builds crashing but the 91677 nightly working fine. Using the official nightly also appears to fix my issue with form filling not working. Sorry again. > > P.S. I get this log message when launching the nightly: 7/25/11 5:31:53.447 PM com.apple.launchd.peruser.501: ([0x0-0x13b13b].org.webkit.nightly.WebKit[95248]) Tried to setup shared memory more than once This may or may not be relevant, but running with gmalloc causes crashes on pretty much any JS website, including cnn.com, due to a pointer bug in the DFG JIT: https://bugs.webkit.org/show_bug.cgi?id=65128 A fix is on the way.
Gavin Barraclough
Comment 5 2011-07-25 15:42:38 PDT
(In reply to comment #3) > Sorry, this appears to be a clang issue, with my local builds crashing but the 91677 nightly working fine. Using the official nightly also appears to fix my issue with form filling not working. Sorry again. No problem. Bug reports are a good thing, better to be overcautious & file. :-)
Gavin Barraclough
Comment 6 2011-07-25 16:34:00 PDT
Closing as invalid per comments above.
Jon
Comment 7 2011-07-25 20:04:44 PDT
I can confirm that this bug disappears, along with my autofill bug, if I compile JSC using llvm-gcc instead of clang. :(
Note You need to log in before you can comment on or make changes to this bug.