Summary: | REGRESSION (r58950): Webkit crashes on clicking back button when in hotmail | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Seamus Roche <seamusjr> | ||||||
Component: | DOM | Assignee: | Alexey Proskuryakov <ap> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | alice.barraclough, ap, beidson, ddkilzer, joepeck | ||||||
Priority: | P1 | Keywords: | InRadar, Regression | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Mac (Intel) | ||||||||
OS: | OS X 10.6 | ||||||||
URL: | http://www.hotmail.com | ||||||||
Attachments: |
|
Description
Seamus Roche
2010-05-12 11:37:39 PDT
has anyone else reproduced this? please comment if you have, thanks! Caused by synchronous document.write fix in bug 38146. I created a Hotmail account, and using the nightly mentioned by the originator (r59204) I habe able to reproduce this problem a few times. Just hammering back / forward and jumping between the Inbox and New message screens. I haven't been able to get concrete steps, so maybe this is based on advertisements. It took a lot longer, but I finally hit an ASSERT in a debug build: ASSERTION FAILED: item->documentSequenceNumber() == history()->currentItem()->documentSequenceNumber() (/Users/pecoraro/Code/webkit-open-source/WebCore/loader/FrameLoader.cpp:3647 void WebCore::FrameLoader::navigateWithinDocument(WebCore::HistoryItem*)) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000bbadbeef 0x00000001017150b8 in WebCore::FrameLoader::navigateWithinDocument (this=0x1118b1850, item=0x105abb6e0) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/FrameLoader.cpp:3647 3647 ASSERT(item->documentSequenceNumber() == history()->currentItem()->documentSequenceNumber()); (gdb) bt #0 0x00000001017150b8 in WebCore::FrameLoader::navigateWithinDocument (this=0x1118b1850, item=0x105abb6e0) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/FrameLoader.cpp:3647 #1 0x00000001017182f0 in WebCore::FrameLoader::loadItem (this=0x1118b1850, item=0x105abb6e0, loadType=WebCore::FrameLoadTypeBack) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/FrameLoader.cpp:3786 #2 0x000000010177f25c in WebCore::HistoryController::recursiveGoToItem (this=0x1118b19c0, item=0x105abb6e0, fromItem=0x119ee8870, type=WebCore::FrameLoadTypeBack) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/HistoryController.cpp:598 #3 0x000000010177f3b8 in WebCore::HistoryController::goToItem (this=0x1118b19c0, targetItem=0x105abb6e0, type=WebCore::FrameLoadTypeBack) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/HistoryController.cpp:231 #4 0x0000000101b98da6 in WebCore::Page::goToItem (this=0x111006a80, item=0x105abb6e0, type=WebCore::FrameLoadTypeBack) at /Users/pecoraro/Code/webkit-open-source/WebCore/page/Page.cpp:308 #5 0x0000000101b98f5e in WebCore::Page::goBack (this=0x111006a80) at /Users/pecoraro/Code/webkit-open-source/WebCore/page/Page.cpp:237 #6 0x0000000100f2becd in -[WebView goBack] (self=0x111005180, _cmd=0x7fff8423c7cc) at /Users/pecoraro/Code/webkit-open-source/WebKit/mac/WebView/WebView.mm:3153 #7 0x0000000100f2165d in -[WebView(WebIBActions) goBack:] (self=0x111005180, _cmd=0x7fff879dd1c1, sender=0x10868b570) at /Users/pecoraro/Code/webkit-open-source/WebKit/mac/WebView/WebView.mm:3854 #8 0x0000000100090540 in ?? () #9 0x00007fff83c818ea in -[NSApplication sendAction:to:from:] () #10 0x00000001000498cd in ?? () #11 0x00007fff83c81849 in -[NSControl sendAction:to:] () #12 0x00007fff83d0d8d0 in -[NSSegmentedCell _sendActionFrom:] () #13 0x00007fff83d0d1af in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] () #14 0x00007fff83d0c6c7 in -[NSSegmentedCell trackMouse:inRect:ofView:untilMouseUp:] () #15 0x00007fff83d0bc59 in -[NSControl mouseDown:] () #16 0x00007fff83c25f1b in -[NSWindow sendEvent:] () #17 0x00000001000456c3 in ?? () #18 0x000000010011eb72 in ?? () #19 0x00007fff83b5b662 in -[NSApplication sendEvent:] () #20 0x0000000100030e66 in ?? () #21 0x00007fff83af20aa in -[NSApplication run] () #22 0x00007fff83aead7c in NSApplicationMain () #23 0x0000000100001d78 in ?? () After commenting out (but logging) when I hit the above ASSERT it looks like that doesn't cause a crash. Doing some more "stress testing" of back & forward I hit the following ASSERT. The other assert didn't appear to have been hit. ASSERTION FAILED: !cachedPage || cachedPage->document() == m_frame->document() (/Users/pecoraro/Code/webkit-open-source/WebCore/loader/HistoryController.cpp:197 void WebCore::HistoryController::invalidateCurrentItemCachedPage()) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000bbadbeef 0x000000010177e9bf in WebCore::HistoryController::invalidateCurrentItemCachedPage (this=0x1130249c0) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/HistoryController.cpp:197 197 ASSERT(!cachedPage || cachedPage->document() == m_frame->document()); (gdb) bt #0 0x000000010177e9bf in WebCore::HistoryController::invalidateCurrentItemCachedPage (this=0x1130249c0) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/HistoryController.cpp:197 #1 0x0000000101712167 in WebCore::FrameLoader::receivedMainResourceError (this=0x113024850, error=@0x7fff5fbfe540, isComplete=true) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/FrameLoader.cpp:3311 #2 0x0000000101b38aba in WebCore::MainResourceLoader::didCancel (this=0x10807ce00, error=@0x7fff5fbfe540) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/MainResourceLoader.cpp:104 #3 0x0000000101d1db93 in WebCore::ResourceLoader::cancel (this=0x10807ce00, error=@0x7fff5fbfe5a0) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/ResourceLoader.cpp:362 #4 0x0000000101d1d2be in WebCore::ResourceLoader::cancel (this=0x10807ce00) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/ResourceLoader.cpp:352 #5 0x00000001015df406 in WebCore::DocumentLoader::stopLoading (this=0x108043e00, databasePolicy=WebCore::DatabasePolicyStop) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/DocumentLoader.cpp:232 #6 0x000000010170dbcf in WebCore::FrameLoader::stopAllLoaders (this=0x113024850, databasePolicy=WebCore::DatabasePolicyStop) at /Users/pecoraro/Code/webkit-open-source/WebCore/loader/FrameLoader.cpp:2214 #7 0x0000000101b98d8e in WebCore::Page::goToItem (this=0x111e50450, item=0x11abd14a0, type=WebCore::FrameLoadTypeForward) at /Users/pecoraro/Code/webkit-open-source/WebCore/page/Page.cpp:305 #8 0x0000000101b98f2a in WebCore::Page::goForward (this=0x111e50450) at /Users/pecoraro/Code/webkit-open-source/WebCore/page/Page.cpp:248 #9 0x0000000100f2be53 in -[WebView goForward] (self=0x111e4eb10, _cmd=0x7fff8423c7d8) at /Users/pecoraro/Code/webkit-open-source/WebKit/mac/WebView/WebView.mm:3161 #10 0x0000000100f21637 in -[WebView(WebIBActions) goForward:] (self=0x111e4eb10, _cmd=0x7fff879dd1b6, sender=0x105a8ef10) at /Users/pecoraro/Code/webkit-open-source/WebKit/mac/WebView/WebView.mm:3859 #11 0x000000010009180f in ?? () #12 0x00007fff83c818ea in -[NSApplication sendAction:to:from:] () #13 0x00000001000498cd in ?? () #14 0x00007fff83c81849 in -[NSControl sendAction:to:] () #15 0x00007fff83d0d8d0 in -[NSSegmentedCell _sendActionFrom:] () #16 0x00007fff83d0d1af in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] () #17 0x00007fff83d0c6c7 in -[NSSegmentedCell trackMouse:inRect:ofView:untilMouseUp:] () #18 0x00007fff83d0bc59 in -[NSControl mouseDown:] () #19 0x00007fff83c25f1b in -[NSWindow sendEvent:] () #20 0x00000001000456c3 in ?? () #21 0x000000010011eb72 in ?? () #22 0x00007fff83b5b662 in -[NSApplication sendEvent:] () #23 0x0000000100030e66 in ?? () #24 0x00007fff83af20aa in -[NSApplication run] () #25 0x00007fff83aead7c in NSApplicationMain () #26 0x0000000100001d78 in ?? () Current language: auto; currently c++ (gdb) p cachedPage $1 = ('WebCore::CachedPage' *) 0x11ac59c60 (gdb) p cachedPage->document() $2 = (class WebCore::Document *) 0x1142bcc00 (gdb) p m_frame->document() $3 = (class WebCore::Document *) 0x106992600 I still haven't been able to reproduce the exact same crash with my ToT Debug build (r59438). =) FWIW, I never saw any of these history controller assertions. If you can find exact steps to reproduce this, please file a new bug, as it's clearly a different issue. I can only reproduce this with the r59204 nightly. Normally after just a few tries. My steps are. 1. Navigate to hotmail.com 2. Log in. 3. Click "New" for a new email. 4. Click "Inbox" 5. Furiously go back and forth a few times. 6. If that fails Go between "Inbox" and the "Manage Folders" link. I haven't been able to reproduce this on ToT (debug). I just finished a release build. Arg, I hit this with release build: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: 0x000000000000000d, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 com.apple.WebCore 0x0000000100e85f14 WebCore::Document::write(WebCore::SegmentedString const&, WebCore::Document*) + 148 (Document.cpp:223) 1 com.apple.WebCore 0x00000001011c30f8 WebCore::JSHTMLDocument::write(JSC::ExecState*, JSC::ArgList const&) + 24 (JSHTMLDocumentCustom.cpp:162) 2 com.apple.WebCore 0x00000001011bf859 WebCore::jsHTMLDocumentPrototypeFunctionWrite(JSC::ExecState*, JSC::JSObject*, JSC::JSValue, JSC::ArgList const&) + 137 (JSHTMLDocument.cpp:436) 3 ??? 0x000036fb664002f4 0 + 60453380162292 4 com.apple.JavaScriptCore 0x00000001007ce1dc JSC::Interpreter::executeCall(JSC::FunctionExecutable*, JSC::ExecState*, JSC::JSFunction*, JSC::JSObject*, JSC::ArgList const&, JSC::ScopeChainNode*, JSC::JSValue*) + 508 (JITCode.h:77) 5 ??? 0x0000000118954300 0 + 4707402496 6 ??? 0x0000000119146780 0 + 4715734912 7 com.apple.WebCore 0x0000000101173410 WebCore::JSDOMWindowShell::~JSDOMWindowShell() + 0 (JSDOMWindowShell.cpp:54) 8 ??? 0x0000441f0f66ffff 0 + 74900193083391 Weird that I can't get this to reproduce in the nightlies. I've commented out both of the asserts I've hit (in hopes it would lead to the crash) and I put logging there instead. I've managed to reproduce both of those but not produce a crash. I'm calling it a night. Created attachment 56056 [details]
reduced test case (will crash)
Attaching a reduced test case. As mentioned before, the actual fix is trivial, will wrap it up in the morning.
Created attachment 56083 [details]
proposed fix
I removed the helper class, because:
1) I didn't like its name.
2) In a tricky place like this, it's probably best to be explicit about which tokenizer is being accessed.
Technically, it would be just as easy to have the checks in helper class by making it hold a Document pointer.
Comment on attachment 56083 [details] proposed fix > @@ -1978,12 +1955,19 @@ void Document::write(const SegmentedStri > if (!m_tokenizer) > open(ownerDocument); > > - { > - ASSERT(m_tokenizer); > - SynchronousHTMLTokenizerGuard tokenizerGuard(m_tokenizer.get()); > - m_tokenizer->write(text, false); > + ASSERT(m_tokenizer); > + bool wasForcedSynchronous = false; > + HTMLTokenizer* tokenizer = m_tokenizer->asHTMLTokenizer(); > + if (tokenizer) { > + wasForcedSynchronous = tokenizer->forceSynchronous(); > + tokenizer->setForceSynchronous(true); > } > > + m_tokenizer->write(text, false); > + > + if (m_tokenizer && tokenizer && m_tokenizer->asHTMLTokenizer() == tokenizer) > + tokenizer->setForceSynchronous(wasForcedSynchronous); > + Couldn't this last if block also include "!wasForcedSynchronous" as a condition, and it would always tokenizer->setForceSynchronous(false)? r+ with that consideration. Committed <http://trac.webkit.org/changeset/59486>. |